Password changed but user still has access?

This is a HUGE security hole.  You shouldn't have to manually unlink to force a new password be entered.

The right thing is that if a user changes a password, than the current credentials on ALL linked systems should be immediately revoked, and a request for an updated password generated.

While I'm at it, an option to automatically unlink systems idle for a user settable time would be good - I just checked and I had 4 old cell phones and 6 old computers still linked but inactive - I should have an automatic method of cleaning this up.

You shouldn't have to manually unlink to force a new password be entered.

Why? Its how most credentials work on machines. 

It would do my head in having to re-link everything I had every time I changed my password - especially as I'm the only person who uses the devices. 

I just checked and I had 4 old cell phones and 6 old computers still linked but inactive - I should have an automatic method of cleaning this up.

But that leaves the data on your devices. If you unlink via the website then you can ask Dropbox to wipe any data on it. You cannot do that if its unlinked. Nor could you track lost / stolen devices. 

you have to take the extra unlink step, which I would wager most users have never heard of.

Personally I disagree. Most modern syncing tools/similar set up programs work on secure tokens. Changing a password on 99% of iOS device applications does not cause the linked accounts to re-request it for example. 

Bit concerned as I though once the password was changed they would lose their access.

No, you need to actively unlink those peoples Dropboxs from www.dropbox.com/account

Thank you for your help. That's really poor security though isn't it? Normally if you give someone access to your account by sharing the password, if you then change it they should not be able to get back into the account? Come on Dropbox that's a massive security hole?

Normally you wouldn't give somebody access to your account though - its basic security. Would you give them access to your email? No. By giving them your password they could do ANYTHING at all to your account and you'd have no come back at all - permanently delete files, remove your access, change the password/emails, anything. And as you've given them your security you have basically made them co-owner and allowed them to do it.

Especially when there are inbuilt features to enable you to not need to do that (shared folders)

To expand a bit more, the standard action if a security breakin is suspected is to change a password, but on dropbox, as currently configured that's useless - once a "bad guy" is in to your account, i.e. linked, changing a password does no good - you have to take the extra unlink step, which I would wager most users have never heard of.

Most systems (e.g. windows) at least require a password entry on reboot - dropbox doesn't even do that - the old credentials are still valid across a reboot, at least on windows, and I suspect other platforms as well. 

As far as other platforms not invalidating tokens when passwords change, that doesn't make it right - in fact, the right (i.e. secure) way to do this is to ask on password reset if the current tokens, links, etc. be invalidated.  Just because other people jump off a cliff doesn't mean it's a good idea.  The basic rule of security is to err on the side of too much authentication, not too little!

You are right about my auto unlink suggestion, but that's easily remedied - just add the option on the auto unlink to erase the data, and make it the default.  In my case, it's irrelevant - all of these devices are known to be dead or upgraded to new identities. 

As far as tracking lost/stolen devices - I don't see how dropbox can help there anyway.

the old credentials are still valid across a reboot, at least on windows, and I suspect other platforms as well. 

It is, thats right, because Dropbox doesnt run on passwords - as was said, it runs on tokens. 

but tokens can be invalidated from the server side, or rejected at boot time.  Now you're just telling me because it's inconvenient to be more secure for the architecture, therefore it's secure - a very bad argument.