Re:The Definitive Guide To Website Authentication
by stephenemslie on Monday August 08, 2011 @12:18PM
(#2860568)
Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.
Re:The Definitive Guide To Website Authentication
by tptacek on Monday August 08, 2011 @12:19PM
(#2860575)
Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.
Re:The Definitive Guide To Website Authentication
by lhnn on Monday August 08, 2011 @04:51PM
(#2861535)
Though they might be the best people, and though I have Duckduckgo on my side, it might be useful to post a citation.
EDIT: To practice what I preach: Duo Song has made an impressive network sniffer and some other cool stuff, and Jon apparently is a security guru who, among other things, has found several security related Android bugs.
Re:The Definitive Guide To Website Authentication
by drivebyacct2 on Monday August 08, 2011 @01:43PM
(#2860871)
Why would I want to use this instead of using Google Authenticator with RFC4226 or TOTP (http://tools.ietf.org/id/draft-mraihi-totp-timebased-06.txt) ?
Looks like Duo has more options for receiving the code as well as the ability to enable manual approve/deny for another user role. It also looks like a private service I have to rely on though.
Re:The Definitive Guide To Website Authentication
by tptacek on Monday August 08, 2011 @01:47PM
(#2860886)
It's not tied to a Google account, it has a better end-user experience, a better developer experience, and an extremely credible team behind it. That said, if you were using Google Auth and I assessed your application, I wouldn't ding you for using it.
Re:The Definitive Guide To Website Authentication
by ceejayoz on Monday August 08, 2011 @10:13PM
(#2862492)
Google Authenticator isn't tied to a Google account, and developing for it involves implementing a single algorithm.
Re:The Definitive Guide To Website Authentication
by drivebyacct2 on Monday August 08, 2011 @02:04PM
(#2860975)
Well the Google Authenticator application is just an implementation. I can use any TOTP generator to get access to my Google Account, or alternatively if I use the PAM module they've provided, I can use whatever I want to generate my codes to log in to my Linux machine. It just so happens that they use this mechanism for their two factor auth for Google Accounts.
I definitely hear you on the better user/dev experience. That's very clear from the variety of methods and slick screenshots they've got.
It is, notably, not enough to safeguard the JS code with HTTPS/TLS (which, if you do that, SRP is of virtually no utility anyways). To protect the Javascript runtime, you'd also need to ensure that no element of the page was ever cached from a non-HTTPS connection, that no element of the page is currently fed from a non-HTTPS connection, and that the page is free from any and all DOM or CSS corruption issues.
Obviously, you'd also need to implement SRP safely, which very few people do; more than half of the SRP implementations I've ever tested have been trivially bypassed due to math flaws.
SRP is a terrible suggestion for generalist devs and for authentication in a web setting. If you want to do something advanced, go two-factor; I like Duo Security, which will be easier for you to integrate than SRP anyways:
http://www.duosecurity.com/