I wouldn't mind seeing it in PHP or Javascript or something. Anything I'd be able to drop into my DIY projects.
-- Hans Kokx On Friday, December 21, 2012 at 11:57 AM, Robin Wood wrote: > On 21 December 2012 16:03, Sandro Gauci <[email protected] > (mailto:[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] > > (mailto:[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] (mailto:[email protected]) > > > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > > > Main Web Site: http://pauldotcom.com > > > > > > > _______________________________________________ > > Pauldotcom mailing list > > [email protected] (mailto:[email protected]) > > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > > Main Web Site: http://pauldotcom.com > > > > _______________________________________________ > Pauldotcom mailing list > [email protected] (mailto:[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
