31–40 of 44 posts
Earlier quoted context omitted.
You could just throw recent login attempts into a table, but that might get big quickly.
or memcachedb, or just use mollom.com
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.
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…
We all make mistakes, doesn't seem terrible honestly.
Earlier quoted context omitted.
Limiting attempts is a great way to allow people to remotely execute a DoS on your admin site. They can keep you out for awhile before you block them. If your company has a password lockout policy, keep guessing the CEO or CIOs password constantly for a few days and the policy will be changed pretty quickly. The other suggestions are good.
You don't lockout the account, you lockout the attacking client, typically by IP address. It still allows the attacked accounts access from non-attacking IP addresses.
Earlier quoted context omitted.
You don't lockout the account, you lockout the attacking client, typically by IP address. It still allows the attacked accounts access from non-attacking IP addresses.
and if the attacking client is someone sitting on the corporate internet? way to block the entire corp from logging in ...
Earlier quoted context omitted.
and if the attacking client is someone sitting on the corporate internet? way to block the entire corp from logging in ...
It seems like the three main strategies are locking the account, blocking the IP, or forcing a password reset. What if instead, the account login name automatically got changed after a few missed attempts but the password remained the same. That would get around the DoS problem and also the corporate IP / AOL problem.
He also realized he hadn't used a proxy to hide his IP address, potentially making him traceable. He didn't think the intrusion was important draw for law-enforcement attention, and "didn't think it would make headlines. I don't understand how he thought hi-jacking Obama, Britney and Fox News twitter accounts wouldn't make headlines.
I don't understand how he thought hi-jacking Obama, Britney and Fox News twitter accounts wouldn't make headlines. He was hijacking a random account on some totally unknown site called twitter. I know this is hard to grasp outside the valley, but most people have not ever heard about twitter and will probably assume it's about as important to the internet as zombo.com.
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.
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…
Earlier quoted context omitted.
It seems like the three main strategies are locking the account, blocking the IP, or forcing a password reset. What if instead, the account login name automatically got changed after a few missed attempts but the password remained the same. That would get around the DoS problem and also the corporate IP / AOL problem.
I think rate limiting is a better option. If you only allow one log in attempt per X seconds, it becomes much harder to do a dictionary attack in a reasonable amount of time.