2 ms·
It is the only way if the action is labeled "save password," rather than "stay signed in" or "authorize this device" or similar. It's a subtle distinction for
by sowbug 7y ago
It is the only way if the action is labeled "save password," rather than "stay signed in" or "authorize this device" or similar.
It's a subtle distinction for the average user who doesn't care, but for a sophisticated user it does indicate a specific kind of behavior, and the relevance is what you do in case of compromise. Do you change your password and make the eavesdropped one useless? Do you deauthorize the stolen computer via a centralized interface?
- Dylan16807 7y ago"the only way" Don't let pedantic adherence to the wording of the UI be more important than security.
- comex 7y agoRight, but that means that what you actually want to do is store a hash of the password salted based on the identity of the machine you’re connecting to. (And the authentication protocol would be changed to verify possession of that hash rather than the password itself.) That way, not only do you avoid leaking the password itself, you ensure the hash can’t be used to connect to any other machines that use the same password. But changing the password is still what you need to do to block future access, preserving the expected semantics for sophisticated users. (For bonus points, the salt should be re-randomized whenever the password changes, so that changing the password makes old hashes permanently useless, even if someone later changes the password back to its old value. Not that going back to an old password is ever a good idea, but some users will inevitably do it anyway.) Edit: Actually, it’s probably better to use a completely random token and just have the server reset it whenever the password changes. That avoids any possibility of cracking the hash to recover the original password.