On 21 December 2012 16:03, Sandro Gauci <[email protected]> wrote: > I like the idea described (using email, OTP etc) but sometimes (or > quite often in my case) the clients wouldn't want to change their > login system to use anything other than what they're currently using > (i.e. username and password). > > In that case, I think detection and slowing down of bruteforce attack > may be of some value. Most users will try a couple of usernames until > they hit one that is not used and then settle down with that username. > Bruteforce attacks, on the other hand, will usually keep trying even > after finding a username that is not used. Therefore the behavior is > clearly different. There's also frequency (i.e. how fast each username > is tested). I think all these factors can be used to make bruteforce > attacks less feasible by temporarily blocking registration for the > attacker. Of course, if you're blocking IP addresses, you might get > distributed attacks from proxies which may be detectable but hard to > block completely. > > This sort of thing would still leak information but hopefully mitigate > the attack by making it slow enough to send the attacker elsewhere.
I always recommend some kind of lockout policy, either complete lockout based on IP or implementation of an incremental delay which won't really affect normal users but will make automation a pain. I'm debating building this into a framework, anyone out there be interested in it if I did? Robin > On Thu, Dec 20, 2012 at 6:56 PM, Zate <[email protected]> wrote: >> >>> If you dropped the random four digits would you get problems with >>> impersonation where one Bugsbunny could pretend to be another once in >>> the system? >> >> >> Yeah you need the 4 digits to maintain uniqueness of the persona. You could >> represent them without it on the UI such as "Welcome back Bugsbunny" instead >> of "Welcome back Bugsbunny.7854" but you need to maintain uniqueness for the >> item you are using for Auth and I'd prefer in my system to use persona >> rather than email address. Never have to change persona, but you might need >> to change email address. >> >>> >>> >>> Someone on Twitter pointed out that maybe the user names should not be >>> private and I've been thinking about that. If you have good >>> protections in place to prevent things like password brute force what >>> is the issue with attackers finding the names of system users. If the >>> system is implemented like you suggest and personas are used rather >>> than email addresses then if someone wants to stay anonymous they just >>> avoid re-use of a persona across multiple systems. I have a feeling >>> that this is wrong but can't put my finger on why. >>> >> >> Persona/username wouldn't be private. if it was a forum, it's be right >> beside the post you made etc. The other bonus to using 4 digits is >> uniqueness per ecosystem. If Game/App A where I am SnowWhite gets popped, >> we often see the bad guys try Game/App B with SnowWhite and the same >> password. If i am SnowWhite.2190 on game A and SnowWhite.2345 on B, the bad >> guys have no real way to know that from the dump they got from Game A's >> poorly secured forums. Yeah I need to remember my username on 2 systems but >> I can always recover if need be. >> >> And yes, you can use diff personas across duff systems entirely, allowing >> you to be anonymous on the new system even while keeping the same email >> address. >> >> I've seen instances where Place X gets compromised, and immediately 24 hours >> later our brute force alarms would go off as the email/pass list from Place >> X was ran over our system. We had a lot of other systems in place (such as >> some amazing in app logging, machine/browser finger printing and Splunk, >> wonderful awesome never leave home without it Splunk) and we were able to >> find compromised accounts in minutes and reset the password almost on an >> automated basis. Had to piss off some of the bad guys for sure. >> >> >> >>> >>> That sounds like a good idea. Assume they attempt to log in and after >>> successful authentication they are securely sent a OTP which then lets >>> them finish authentication. If the OTP is used before successful >>> authentication then an attacker could flood a valid user with OTPs. >> >> >> Correct. The OTP was used after a successful auth from a system not in the >> whitelist. Lots of sites do it today, Steam is a good example. Code gets >> sent to your email address (and as such you are trusting the user owns their >> email account, if they dont, well they probably have a host of other >> problems) and then you enter it. >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
