in reply to Passwords, hashes, and salt

You're using a two-character salt, different for every user, which is viewable as part of the hash. I'm suggesting pretty much the same thing, except the user name is the unique part of the salt and the process is more obfuscated. What am I missing here? Did you think I wasn't going to MD5 or SHA-1 the result? Heh.

Incidently, I fail to see how any security method is going to save you if the person with root gets pissed off. He can social engineer people; he can redirect himself a copy of their user names and passwords on login; he can scan data streams and memory; etc. All he needs is a few logins to make your entire database unsafe, unless you know exactly which ones he has. Face it, you're screwed. The only thing you can prevent is him knowing everyone's password in one easy step, but why would that matter when he has root? He controls everything.

EDIT: I suppose if you know who logged in when and also when it was he inserted the redirect, you could identify which users he had the login info for and reset just their passwords. To prevent this, he'd also have to edit the logs before every site backup, which I admit would add a level of complexity to things. Still, anyone with half a brain would most likely have no trouble doing this.

Replies are listed 'Best First'.
Re^2: Passwords, hashes, and salt
by waswas-fng (Curate) on Jun 27, 2005 at 15:09 UTC
    All I can say is that there is very good reason that unix password files have been trap door encrypted for decades. One of the foundational principles in security is that given enough time and want any system can be broken. This does not mean that you give up on the details. You have a few doors with locks on them at your house, what is the point when you have very breakable windows right next to them? Thats what I read in your response.

    You Said: Just merge the user name and password and salt in such a way that the hash is unique for every user name and password pair, and completely unguessable through dictionary attack or brute force

    Which is one of the things in your post that made me realize you did not have your eye on the prize. Salt guess-ability is not a factor, they do their job while being totally known and visible. in fact you could just inc 01 .. N for salt on each new username and be done --all that matters really is that they are different per password. All your suggestion does in this post is to try to obfu salt into the password/hash -- this buys you nothing.

    Later on you say: Personally though, I'd work more on making sure the database is secure from prying eyes, rather than hashing stored passwords. Storing passwords as irreversible hashes means there's no way to retrieve the password if the password is forgotten, meaning in turn that you need a secondary verification system - which is always less secure and usually fairly easy to social engineer. If you ARE going to make passwords irreversible, make them short (no more than 3-4 alphanumeric characters), with lock-out of IP / user on failure to log in 3 times in a row. A short password is much easier to remember, and pretty much eliminates the need for a secondary verification system.

    which I see so many issues with I cant really spend the time going into it in detail. All I will say is that the second level password reset systems are as secure as they are designed to be -- while your posting account on perlmonks may be easy to get reset, your cert and pass at a DOD installation may require physical request with ID. It is all in the design and risk assessment of the particular site -- You have to remember at the end of the day user:pass systems are there to verify identity. If anyone on your system can freely grab user:pass info -- they can't be used to verify identity.



    -Waswas
[reply]

In Section Seekers of Perl Wisdom