5 ms·

This does bring up a good tech question -- how do you prevent people from doing a rapid password attack? Anyone have an article or some ideas on how this could

by bprater 18y ago

This does bring up a good tech question -- how do you prevent people from doing a rapid password attack? Anyone have an article or some ideas on how this could be done? Is limiting attempts the simplest way? Even if you do limits, aren't these session-based? I'm guessing a cracker isn't going to respect sessions.

fuzzmeister 18y ago
You could just throw recent login attempts into a table, but that might get big quickly.
- liuliu 18y ago
  or memcachedb, or just use mollom.com
  - aniketh 18y ago
    didn't realize an alternative to akismet existed... quick question : how come mollom says 78% of comments are spam, but akismet says 85%?
- shaunxcode 18y ago
  and thus could also be archived/truncated frequently as it is only relevant within a certain time frame right?
- catch23 18y ago
  why even bother logging that? just store it in memory someone. have a counting bloom filter remember the set of IPs that tried to login during the last 10 seconds. If your ip is in that set, delay the user by 10 seconds or so...
  - amix 18y ago
    memcached is great for these kind of things.
dmoney 18y ago
You could double the response time for every successive attempt from the same IP. You'd still need an absolute limit on the account, in case of a distributed attack.
nuclear_eclipse 18y ago
Look at how programs like Fail2Ban, and many SSH-specific monitoring services work. Specifically, Fail2Ban follows auth logs for various services, and when it finds clients exceeding per-service configured limits, it adds IPTables rules that ban the offending IP address for a configurable amount of time. Fail2Ban is packaged in many distributions, including Debian and Ubuntu, and can be compiled on just about any system. I personally use it exclusively to thwart brute force attacks on SSH, SMTP/Postfix, IMAP/Dovecot, and HTTP/Apache. It should be trivial to add a new set of filter/jail rules for any web application that can log bad authentication attempts to a file, and then you have instant "protection" from most brute force attacks.
Tangurena 18y ago
Presume that you have some sort of table with userIDs and password hashes (with salt). You should also consider adding some columns like: 1 - LastLoginAttemptedDateTime 2 - LastLoginAttemptedIPAddress 3 - LastSuccessfulLoginDateTime 4 - LastSuccessfulLoginIPAddress 5 - MustChagePasswordAtNextLogin - a boolean flag to indicate they must change their password. You'll set that flag when they're recovering a password, or you've emailed them a temporary password. 6 - UnsuccessfulLoginCount - some number that your logic will use to determine how long they must wait, or if they sit in the penalty box. 7 - AccountLocked - boolean flag, some pointy haired bosses will not permit accounts to be locked out, like mine. And mine refuses to allow passwords to be one-way hashes (his words: we must be able to email the user the password they use). Depending on the security you need, the user of a locked account either has to phone up an unhelp desk, or show up in person. 8 - UserAgreementID - As you change user agreements, you'll want to keep track of what agreement the user agreed to, what day and time. This is something you'll want to log, and if you make substantial changes to the user agreement, you may want to force them to re-agree to the terms of use. You will also want to keep every version of the user agreement stashed away in a table somewhere, in case the lawyers get involved. 9 - UserAgreementDateTime - see #8 Along with a LoginTransaction table that captures attempts - both successful and not to log in, with usernames, date/time, IPaddress. This table should locked down so that a hacker can't delete entries, entries can be added, but not deleted nor changed. You'll do that with triggers ("instead of" triggers for sql server folks). Perhaps your business logic says that a user can have 3 attempts in a 5 minute window (with no lockouts). Your code would do something like...user has made 3rd bad attempts, set LastLoginAttemptedDateTime = Now, set UnsuccessfulLoginCount = 3. Now the user tries to log in 1 minute later...If LastLoginAttemptedDateTime + 5_minutes < Now then log the attempt, LastLoginAttemptedDateTime = Now, reject login attempt EndIf. If they log in successfully, log that event, set UnsuccessfulLoginCount = 0, set LastSuccessfulLoginDateTime and LastSuccessfulLoginIPAddress to the appropriate values.
- gojomo 18y ago
  And if the attacker doesn't care which userID they compromise, so they spread their guesses over all userIDs?
  - 18y ago

by bprater 18y ago

fuzzmeister 18y ago

You could just throw recent login attempts into a table, but that might get big quickly.

liuliu 18y ago
or memcachedb, or just use mollom.com
- aniketh 18y ago
  didn't realize an alternative to akismet existed... quick question : how come mollom says 78% of comments are spam, but akismet says 85%?
shaunxcode 18y ago
and thus could also be archived/truncated frequently as it is only relevant within a certain time frame right?
catch23 18y ago
why even bother logging that? just store it in memory someone. have a counting bloom filter remember the set of IPs that tried to login during the last 10 seconds. If your ip is in that set, delay the user by 10 seconds or so...
- amix 18y ago
  memcached is great for these kind of things.

dmoney 18y ago

You could double the response time for every successive attempt from the same IP. You'd still need an absolute limit on the account, in case of a distributed attack.

nuclear_eclipse 18y ago

Look at how programs like Fail2Ban, and many SSH-specific monitoring services work. Specifically, Fail2Ban follows auth logs for various services, and when it finds clients exceeding per-service configured limits, it adds IPTables rules that ban the offending IP address for a configurable amount of time. Fail2Ban is packaged in many distributions, including Debian and Ubuntu, and can be compiled on just about any system. I personally use it exclusively to thwart brute force attacks on SSH, SMTP/Postfix, IMAP/Dovecot, and HTTP/Apache. It should be trivial to add a new set of filter/jail rules for any web application that can log bad authentication attempts to a file, and then you have instant "protection" from most brute force attacks.

Tangurena 18y ago

Presume that you have some sort of table with userIDs and password hashes (with salt). You should also consider adding some columns like: 1 - LastLoginAttemptedDateTime 2 - LastLoginAttemptedIPAddress 3 - LastSuccessfulLoginDateTime 4 - LastSuccessfulLoginIPAddress 5 - MustChagePasswordAtNextLogin - a boolean flag to indicate they must change their password. You'll set that flag when they're recovering a password, or you've emailed them a temporary password. 6 - UnsuccessfulLoginCount - some number that your logic will use to determine how long they must wait, or if they sit in the penalty box. 7 - AccountLocked - boolean flag, some pointy haired bosses will not permit accounts to be locked out, like mine. And mine refuses to allow passwords to be one-way hashes (his words: we must be able to email the user the password they use). Depending on the security you need, the user of a locked account either has to phone up an unhelp desk, or show up in person. 8 - UserAgreementID - As you change user agreements, you'll want to keep track of what agreement the user agreed to, what day and time. This is something you'll want to log, and if you make substantial changes to the user agreement, you may want to force them to re-agree to the terms of use. You will also want to keep every version of the user agreement stashed away in a table somewhere, in case the lawyers get involved. 9 - UserAgreementDateTime - see #8 Along with a LoginTransaction table that captures attempts - both successful and not to log in, with usernames, date/time, IPaddress. This table should locked down so that a hacker can't delete entries, entries can be added, but not deleted nor changed. You'll do that with triggers ("instead of" triggers for sql server folks). Perhaps your business logic says that a user can have 3 attempts in a 5 minute window (with no lockouts). Your code would do something like...user has made 3rd bad attempts, set LastLoginAttemptedDateTime = Now, set UnsuccessfulLoginCount = 3. Now the user tries to log in 1 minute later...If LastLoginAttemptedDateTime + 5_minutes < Now then log the attempt, LastLoginAttemptedDateTime = Now, reject login attempt EndIf. If they log in successfully, log that event, set UnsuccessfulLoginCount = 0, set LastSuccessfulLoginDateTime and LastSuccessfulLoginIPAddress to the appropriate values.

gojomo 18y ago
And if the attacker doesn't care which userID they compromise, so they spread their guesses over all userIDs?
- 18y ago