* On Wed, May 20 2009, Arthur Corliss wrote:
On Wed, 20 May 2009, Jonathan Yu wrote:
Not totally pointless, of course, because it would still require
regenerating a rainbow table versus downloading one of them already
available. On the other hand, depending how popular your application
gets,
Bill Ward writes:
I didn't think that a salt was necessary with a one-way hash.
Google makes even the best hash functions reversible for some inputs:
http://www.google.com/search?q=5d41402abc4b2a76b9719d911017c592
http://www.google.com/search?q=aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
It's my understanding that the margin by which storing a hashed
password without a salt is better is related to its length. It's
harder to calculate/store SHA-512 hashes versus SHA-1, right? I mean,
takes a lot more time space to construct rainbow tables, and thus
could be infeasible to generate.
Jonathan Yu writes:
It's my understanding that the margin by which storing a hashed
password without a salt is better is related to its length. It's
harder to calculate/store SHA-512 hashes versus SHA-1, right? I mean,
takes a lot more time space to construct rainbow tables, and thus
could
On Thu, May 21, 2009 at 11:04:02AM -0400, Jonathan Yu wrote:
[snip]
Interesting idea though, using Google to reverse hashes... in that
case you wouldn't even need to know the algorithm used to hash it!
Erm... not really. There are many hash algorithms that give outputs
with the same length;
Over the years I've developed my own private Perl web login module. It
takes a username or email address and password, checks it against the
database, and creates the cookies. It has a 'forgot my password' option
which is reasonably secure (of course it assumes that the email address of
record
Hi:
Well, some things I can think of are:
1. Use SHA-256 instead of MD5. Even SHA-1 is thought to be possibly
weak, and there have been collisions detected against MD5, worse for
MD's predecessors like MD4. If not SHA, then there are lots of other
great algorithms like WHIRLPOOL that are worth
Bill:
To clarify why a salt is necessary, consider the classic time-space
tradeoff. Let's say I know that your password is exactly 8 characters
long and I know all of the possible characters it could be. So let's
say it's alphanumeric (a-z, A-Z, 0-9, hyphen, period, underscore) -
that's
On Wed, 20 May 2009, Bill Ward wrote:
2. Make sure to have a salt value, as it prevents the use of rainbow
tables to get a password. So you have the hash and a known salt kept
separately (the salt is plaintext), and when you check the password
you check: sha256(passphrase + salt) ==
A few minor points.
On Wed, May 20, 2009 at 6:00 PM, Arthur Corliss
corl...@digitalmages.com wrote:
On Wed, 20 May 2009, Bill Ward wrote:
2. Make sure to have a salt value, as it prevents the use of rainbow
tables to get a password. So you have the hash and a known salt kept
separately (the
On Wed, May 20, 2009 at 2:55 PM, Jonathan Yu jonathan.i...@gmail.comwrote:
Bill:
To clarify why a salt is necessary, consider the classic time-space
tradeoff. Let's say I know that your password is exactly 8 characters
long and I know all of the possible characters it could be. So let's
say
On Wed, 20 May 2009, Jonathan Yu wrote:
There are web sites that specialize in that sort of thing. So having a
2-byte salt can really help stop those attacks, or at least make the
amount of space needed infeasible (since every different 2 character
salt will require you to generate an entirely
On Wed, 20 May 2009, Jonathan Yu wrote:
Not totally pointless, of course, because it would still require
regenerating a rainbow table versus downloading one of them already
available. On the other hand, depending how popular your application
gets, this can be dangerous -- take for example
On Wed, May 20, 2009 at 6:13 PM, Arthur Corliss
corl...@digitalmages.com wrote:
On Wed, 20 May 2009, Jonathan Yu wrote:
Not totally pointless, of course, because it would still require
regenerating a rainbow table versus downloading one of them already
available. On the other hand, depending
The passwords are stored in a database table, not a file, so that exact
scenario won't work. But one could easily imagine some SQL injection attack
or something like that making the passwords visible - which is a big reason
I store them as MD5 hash values rather than plaintext. It certainly
On Wed, 20 May 2009, Jonathan Yu wrote:
That's a pretty valid point. If it's a simple auth system as I
understand it, though, then the users don't have different
permissions, so there's really no point in cracking *all* of the
passwords if you can download all the data with one.
No arguments
On May 20, 2009, at 4:24 PM, Bill Ward wrote:
Over the years I've developed my own private Perl web login module.
It takes a username or email address and password, checks it against
the database, and creates the cookies. It has a 'forgot my
password' option which is reasonably secure
17 matches
Mail list logo
