Storing passwords locally
I'm looking for a way to take the address, user-ID, and password for a server, and store it securely on a client box.
I've been running some experiments, and have learned how to encrypt and decrypt data, given a known SecretKey, but that, by itself, amounts to nothing more than "security-by-obscurity," since it would be easy enough to work out the base material for the key from even an obfuscated jar.
Can anybody point me in the right direction for what I'm looking for?
--
JHHL
# 1
> Can anybody point me in the right direction for what
> I'm looking for?
>
Not really! Your best bet is to store the information in some repository that is passphase or password protected but even that is not really secure since anyone could tamper with your code and arrange to expose the passphrase/password when you type it in.
# 2
Normally passwords aren't encrypted, they are one-way hashed, and the hashes compared.
If you don't encrypt them they can't be decrypted.
Last time I saw an OS that encrypted passwords was the 1970s, and believe me I could walk into any of my customer's sites and become the super-super-user because of this deficiency.
ejpa at 2007-7-9 20:34:38 >
# 3
Encrypting passwords is really a terrible idea. But I'm sure, my bank DOES store the password used for internet banking (encrypted or not, they was able to tell me).
Hashing is much better, but hashing on the client computer wouldn't help anyway, as the only thing you need for login using this schema is the hash value (and not the password itself).
# 4
Actually, a number of IBM's own servers can use a technique called "password substitution," in which the password is never transmitted: a seed value is sent from the server to the client, and that seed is combined with the password to generate an encryption key that is in turn used to encrypt the user-ID. This encrypted user-ID is then sent, along with the clear user-ID.
Unfortunately, we can't do that with our server, because there's no way for an application to retrieve the password (at least, I hope there isn't).
But we don't acutally need the password on the server side, except to confirm the user's identity. And we could do that, once the user has signed on at least once, if we have a one-way hash of the password cached on both the client and the server. While even that could be stolen, it couldn't be used to access anything but our server.
Unfortunately, there's another problem with that: if we decouple this completely from password checking, then the cached hashes will remain valid even when the password is changed or expires. YEEF!!
You see client applications with password caching all the time. You see WinDoze offering to cache passwords for you all the time. You sign on to boards like MousePad, or the Star Trek Books board at SimonSays, and check the "remember me" box, and your password gets saved in a cookie! Surely there's SOME practical way to offer users this option in a Java client!
# 5
> Encrypting passwords is really a terrible idea.
Although this is conventional wisdom there is one major disadvantage with hashing. It is impossible for a user to request his password when he forgets it.
To deal with this, the approach I use is to give the user a 'one operation password' so that he can log in with the password and then the only operation he is allowed to do is change the password.
# 6
"one operation passwords" are hardly uncommon. A common practice in OS/400 is to set up new user accounts with the password pre-expired, forcing the user to change it immediately on first sign-on. They also seem to be fairly common with web sites requiring passwords.
But the issue here is password caching in a client.
# 7
> "one operation passwords" are hardly uncommon.
I didn't say they were! I just said it was an approach I use.
>
> But the issue here is password caching in a
> client.
OK! I was responding to the comment about hashing passwords. Sorry to have polluted your thread.
# 8
Think nothing of it; I was merely commenting on the "one operation password" approach being common, and attempting to restate what I might not have been clear about. I certainly have nothing to take offense at, and hope I haven't given any offense, either.
# 9
I don't think, it is possible to do more than just somehow obfuscate the password. If it is stored, then anybody having enough time and access to the computer, can read it.
If just a hash is stored, then anybody having enough time and access to the computer, can read the hash and use it for login. However, the password (probably used in 100 other places) stays secret.
You can encrypt the password using the server public key. At the moment it seems to me to be somehow better than hashing, but it's just an idea. Of course, it assumes your server to be secure.
You wrote "Unfortunately, there's another problem with that: if we decouple this completely from password checking, then the cached hashes will remain valid even when the password is changed or expires.". I'm quite sure the problem can be solved, do you need some ideas how to do it?
