Re: Best way to encrypt password in database.

Captain Paralytic wrote:
On Jan 7, 5:03 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> wrote:
Captain Paralytic wrote:
On Jan 7, 1:17 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> wrote:
r0g wrote:
Jerry Stuckle wrote:
r0g wrote:
r0g wrote:
The Natural Philosopher wrote:
Thinking seriously about security.
I want a way to store an undecryptable password, so that the sysadmins
don't know what it is etc etc.
And so I can pass it back and forwards without it being in clear text.
Probably over paranoid, but heck..who isn't these days?
Anyway the theory is that the user enters it once, and the rest of the
session some kind of hash is used to validate the session.
So basicaly a
function return_encrpted_password($users_passwd)
{
return some_magic($user_passwd)
}
where what comes back is uniquely IDed with the password, and is ASCII
only, but cannot easily be used to deduce what the password was.
Yep, that's the traditional way to do it, hash the password every logon
and compare it to a stored password hash. The spanners in the works
though are weak passwords and rainbow tables... If you password hashes
are compromised they can be compared to precomputed hashes for some
truly enormous dictionaries and, unless you have extremely well drilled
users or a draconian password policy you'll find many of your users
passwords succumb to this kind of attack. My tests in python with a very
modest word list and no rainbow tables managed to crack about 25% of the
passwords of a 4000 subscriber site within 10 minutes so I would say the
above technique on its own is only marginally better than obfuscation.
The fix is to add a salt to thwart the rainbow tables and a have the
password encryption routine do a large number of rehashes/rounds (think
a few hundred) to make brute force attacks painfully slow.
Check out the latest Drupal, they recently ditched the old school
password encryption method in favour of the above approach and all the
code is in PHP.
Roger.
Oh and BTW, never use MD5 for anything security related, it is broken
and getting brokener. SHA1 has also been shown to have weaknesses. I
would recommend SHA128 for passwords.
Roger.
Incorrect. MD5 is not broken.
The weakness is in that you can create the same MD5 hash by making
specific changes in the source text. But in order to create that hash,
you must have the original source.
Without the original password (or other source), MD5 is just as secure
as any of the other hashes of similar size.
Good point Jerry, in this particular context it may well be as good as
SHA128, but it's no longer considered cryptographically secure so it
shouldn't be used for signing or forensics for example. There was a
proof of concept exploit over a year ago that leverage it to get fake
root SSL certificates issued and collisions can be generated on a scale
of days now, not months or years. Call me paranoid but I'm of the
opinion once the cracks start appearing it's a prudent time to upgrade,
especially as superior stuff is freely available.
The widespread existence of rainbow tables for it would make me nervous
about using it bare too. The only time I can image where you might want
to use it is if you're on an embedded processor. In all other cases why
not burn a few more cycles to get a state of the art hash instead of a
20 year old one?
Roger.
Yes, I agree - it shouldn't be used for signing/forensics. But rainbow
tables for it are overstated. There are 36^32 possible keys - which
comes out to 6.3340286662973277706162286946812e+49 according to Windows
calc. Even at 1 byte per entry (which there isn't), that would be over
5.7e+37 terabytes just for all the possible hashes. There isn't that
much storage in the entire world. Even a relatively small subset would
take huge amounts of storage.
Yes, there are others ones available, and I agree some are even faster
than md5. I like sha1, myself. But I was just addressing the comment
that md5 is not secure. In this context it is.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@xxxxxxxxxxxxx
==================
Any of these one way hashes still needs a salt combined with it. There
are md5 and sha1 databases available which can "decrypt" many of the
"trivial" passwords in use. This was a problem with the older Joomla
password management. They now combine the password with a salt string
which makes using one of these databases to get back to the original
password impossible.
Just for research, a while ago I ran the user tables from a couple of
CMS based sites through an online MD5 database using CURL. I got about
a 40% hit rate and you can bet that folks using that sort of trivial
PW will be likely to have used it on all the sites they access.
True, trivial passwords are easy to catch, even with relatively small
tables. That's why I always add characters to the password when I
encrypt them if I'm using an algorithm without a salt.

Of course, if someone gets access to your source files, even that
doesn't help, and an algorithm which takes a separate salt is much
harder to crack.


Joomla now appends a random salt, then md5s then stores the resultant
hash and the random salt. This is enough to ensure that it is never
possible to guess the password from the stored string.

What do they do - use the same salt for all users?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... MD5 is not broken. ... Any of these one way hashes still needs a salt combined with it. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... Oh and BTW, never use MD5 for anything security related, it is broken ... Any of these one way hashes still needs a salt combined with it. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... The fix is to add a salt to thwart the rainbow tables and a have the ... MD5 is not broken. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... session some kind of hash is used to validate the session. ... though are weak passwords and rainbow tables... ... If you password hashes ... MD5 is not broken. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... The fix is to add a salt to thwart the rainbow tables and a have the ... Oh and BTW, never use MD5 for anything security related, it is broken ...
    (comp.lang.php)