

Dictionary Attacks 101 - bdfh42
http://www.codinghorror.com/blog/archives/001206.html

======
sh1mmer
You should also remember to throttle login attempts for accounts that _don't_
exist.

It's important not to create new attack vectors that don't already exist when
implementing security features.

If you don't throttle accounts that don't exist then a brute force attempt can
be used to determine which logins are valid for a given service. This
information can then be combined with targeted phishing attacks, etc.

------
meep
I've found 1Password (<http://agilewebsolutions.com/products/1Password>) to be
a great solution to this. It automatically generates passwords for you and
saves logins on an encrypted file. The only problem I've found with it is that
when you go to use a friend's computer or a public computer you don't always
know your passwords. A web service version of it would be convenient, but the
security implications are obvious..

~~~
timf
For the sake of a working solution I also just store passwords in encrypted
files (using encfs, though) and stop worrying about accessing everything from
my non-main computers.

Script for new passwords follows, for the fun of it. I have stuff added
afterwards to save the username, website, and password to encrypted files.

    
    
      #!/usr/bin/env python
      import string
      from random import Random
      okchars = string.letters + string.digits + "!@%^_&*+-"
      print ''.join( Random().sample(okchars, 40) )

------
fleaflicker
How do you implement a failed login delay?

I assume you'd have to just sleep before sending the response. But this could
tie up all available threads for processing requests and bring down the site
under heavy attack.

~~~
chime
You refuse to allow login during the delay period. That is, after the 5th
failed login, for the next 16 seconds, if the user tries to login, you say
"Wait sometime before trying again." You do not accept and check the
credentials supplied during this time. You simply refuse to begin the
authentication process until the delay period has elapsed.

~~~
timf
And exponential backoff is fine but not when it gets to be too much, it turns
into a DoS problem. You could try to key it by IP and never let it go past,
say, 2 minutes per source IP.

i.e., if me simply knowing someone's account name lets me disable their
account for the next day or longer, that's a big problem.

------
streety
As described I don't really see how the solution proposed handles DoS attacks
any better than a lock out after x failed attempts.

The key to preventing DoS attacks is that the throttling is specific to a
given host so that when the genuine user attempts to log on (presumably from a
different host than the attacker) they can do so without any throttling.

~~~
pchristensen
DoS meaning you can lock people out of their accounts, not that the site is
brought down.

------
viggity
The Plague: Our recent unknown intruder penetrated using the superuser
account, giving him access to our whole system.

Margo: Precisely what you're paid to prevent.

The Plague: Someone didn't bother reading my carefully prepared memo on
commonly-used passwords. Now, then, as I so meticulously pointed out, the four
most-used passwords are: love, sex, secret, and...

Margo: [glares at The Plague]

The Plague: God. So, would your holiness care to change her password?

