Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re^2: Passwords, hashes, and salt

by waswas-fng (Curate)
on Jun 27, 2005 at 15:09 UTC ( #470295=note: print w/replies, xml ) Need Help??

in reply to Re: Passwords, hashes, and salt
in thread Passwords, hashes, and salt

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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://470295]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (8)
As of 2019-05-20 08:42 GMT
Find Nodes?
    Voting Booth?
    Do you enjoy 3D movies?

    Results (125 votes). Check out past polls.