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
12 matches
Mail list logo
