
How I became a password cracker - shawndumas
http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/
======
zobzu
Meh, I had to read all 3 pages to read that the author just didn't load the
word list properly :(

~~~
chickopozo
I want my time back, three pages on basically nothing. I broke into my house
last year because I lost my keys -> brb writing an article titled "How I
became a burglar and locksmith"*

*I took my keys from in the house so... by ars standard that's serious theft.

Rather than reading that article might I suggest having a gander at moxie's
<https://www.cloudcracker.com> and read his blog too for all the goodies.

~~~
enraged_camel
>>I want my time back, three pages on basically nothing.

Yeah, it's shameful that such a poorly written article is being touted as a
"feature story." Then again that's what happens when your editor-in-chief
demands articles of a certain length and you don't have much to say, so you
fill three pages with bullshit. Kind of like in college!

------
shanelja
Regarding your tips on passwords, one technique I used to employ in password
security was the following:

When the user signs up, store a Timestamp for creation date, then take their
email address and use it as a prefix and suffix to salt the password, for
instance:

If the users password is shanelja, then the routine would be as such:

 _TIMESTAMPshaneljaEMAIL_

or in my case:

 _147182994718shaneljashanea93@hotmail.co.uk_

This produces a _ridiculously_ hard password to brute force.

While this may be easy to compute if you know the rule, the general rule of
thumb is that if your server has been attacked in such a way that the attacker
has a copy of your database, they will most likely know the rule in any case,
so it makes sense to have a good one.

Outside of this, no one should be using MD5 in this day and age, I would even
recommend against Sha256 and other variants in that family, though I have a
lot of respect for Blowfish, etc.

~~~
pluies_public
Uh? What's the advantage of this technique over a randomly generated salt?

~~~
jasey
Because part of the puzzle is in the source code, and if the attacker got the
encrypted user table from the common method of SQL injection they don't know
the rule which is defined only in the function which checks validation of the
pw and generates the pw hash.

What I do _similar_ is,

Pw_hash = hash('f4/$$er3@' + salt + plain_text_pw);

If the attacker only gets the database (which has the hash and the salt) and
not the source code they don't have the 'f4/$$er3@' value needed to perform
any attacks

~~~
stouset
There is zero requirement that salts be kept secret in the event of a password
database breach. Salts are to prevent users with identical passwords from
having identical password hashes, thereby defeating rainbow table attacks (and
other attacks involving attackers being able to reuse work from other
accounts).

Your approach offers effectively zero additional security; it is trying to add
"features" to salting that don't work towards their actual purpose.

Edit: If you want to have something site-wide that an attacker wouldn't have
while decrypting an offline password database, the thing you're looking for is
an _encryption key_.

