password generator inspired by XKCD observation...

Started by Darren Dirt, August 12, 2011, 03:54:57 PM

Previous topic - Next topic

Darren Dirt


...that after decades of cracking stories, we humans are now trained to choose hard-to-remember passwords (which often results in folks forgetting them, or writing them down somewhere nearby).


Solution: Four Random Common Words.

http://preshing.com/20110811/xkcd-password-generator

found via http://lifehacker.com/5830355/xkcd-password-generator-creates-long-easy+to+remember-passwords
_____________________

Strive for progress. Not perfection.
_____________________

Lazybones

Doesn't do you any good on sites that have 9 character limits on the password field or do automatic truncation..

What site would do such a bad thing? ONE OF MY BANKING SITES! Not my primary bank but another one I have an account with.

Thorin

I am not a security expert, and do not want to be responsible for ensuring anything is made secure.  The rule with security is that it takes only one weak item in the chain to make it unsecure, and I'm sure I'll make at least one mistake.

That being said, I'm interested in security and the algorithms used.  One of the things I've learned over the years is that security must be done in layers and from the server side, not relying on clients to do security right.

To fight brute force attacks, external systems should not allow hundreds of attempts per second but should instead have a sliding scale of required wait time between attempts; for instances, a delay of seconds equal to the Fibonacci sequence.  This will cause hackers to try to gain access to the servers instead of brute-forcing.

To fight unauthorized access, external and internal systems should be properly protected and separated by firewalls and should be monitored for keyloggers.

In case unauthorized access is gained, internal datastores should hash stored passwords in the best hashing algorithm possible.  This stops the hacker from reading the passwords in the datastore.  Of course, the hacker will then try to determine the hash used so we should salt and then hash the stored passwords.  This ensures that if the hacker manages to determine what one hash means, they won't know any of the other passwords yet.

Still, a requirement of at least six characters is a good idea...
Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful

Lazybones

Quote from: Thorin on August 13, 2011, 01:08:57 PM
Still, a requirement of at least six characters is a good idea...

You missed the point of the XKCD comic... a short complex password is now trivial to defeat with brute force but hard for a human to remember... a long password of simple words is easy to remember and hard for a computer to brute force.

One of the online banking systems I use does not allow me to have a long password, it is LIMITED to 8 or 9 characters, essentially making it easier to compromise assuming brute force is possible, or someone steals the hashed database and it isn't correctly salted.

You are correct on the many points of failure.

1. Trivial user passwords, or password reuse.
2. Systems that allow external brute force by not limiting attempts
3. Hashing passwords is not enough, you must also correctly salt.
4. it is now thought important to hash the login ID as well for storage since many people reused both the login name and password in many systems

Thorin

Not sure I missed that point, I absolutely understand it.  Short passwords, complex or not, are bad.  That's why I said at least six characters.  Otherwise the passphrase could be "I am", which is two words but only four characters (if the space is even allowed).  Or even "I a", two words and three characters.  These would also be easily brute-forced.

Another way to handle this is to require two or more separate passwords in two or more separate fields.  This would force the passphrase.  Royal Bank kinda does that - you have to enter your account number and then your password, and then it asks you for a verification question.  In essence, it's a two-word passphrase (and the verification question is one of a set that you entered, so the second phrase isn't always the same).

Hmm, the more I think about it the forced second password field would do much to allay the brute-force fears.
Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful

Mr. Analog

Don't allow for brute forcing, kill allowable login attempts after x tries or force some kind of CAPTCHA on every try.

I mean if you had a 6 character password and you only allowed 3 tries per day it would take a long time brute forcing that. It could still be done but hopefully the account gets locked after so many repeated incidents (either that or turn it into a fake honeypot account see what the hacker is gonna do with it :D put them in a virtual instance or something)
By Grabthar's Hammer

Darren Dirt

Quote from: Lazybones on August 13, 2011, 01:27:17 PM
a short complex password is now trivial to defeat with brute force but hard for a human to remember... a long password of simple words is easy to remember and hard for a computer to brute force.

yeah, this. which led to the developer making that little webpage thingie.
_____________________

Strive for progress. Not perfection.
_____________________

Lazybones

Quote from: Darren Dirt on August 13, 2011, 06:38:43 PM
Quote from: Lazybones on August 13, 2011, 01:27:17 PM
a short complex password is now trivial to defeat with brute force but hard for a human to remember... a long password of simple words is easy to remember and hard for a computer to brute force.

yeah, this. which led to the developer making that little webpage thingie.

The problem and discussion however is that many systems are restricted to forcing you to use a short hard password or at least a hard password.

Darren Dirt

True (sadly) but then there's other uses for this 4-word generator :)
_____________________

Strive for progress. Not perfection.
_____________________