Ask YC: How do you authenticate users?
I've seen various sites use OpenID, Google, MS Passport, Yahoo, Facebook, and/or other third-party systems to authenticate users. Anyone here using one of those?
12 comments
I asked this question a while back and got some good info. Check out the PDF link provided by mdakin after the jump:
http://news.ycombinator.org/item?id=51422
http://news.ycombinator.org/item?id=51422
Django authentication middleware. It's really, really easy -- like everything in Django.
If you're looking at Python frameworks - TurboGears also has built in Identity Management.
http://docs.turbogears.org/1.0/IdentityManagement?action=sho...
Then there is the AuthKit extension for Pylons. Although I really like Pylons, I had some problems getting AuthKit working with the latest version.
http://docs.turbogears.org/1.0/IdentityManagement?action=sho...
Then there is the AuthKit extension for Pylons. Although I really like Pylons, I had some problems getting AuthKit working with the latest version.
I don't see why anyone would use most of those unless they needed to authenticate users with a third party in order to use their API. Using OpenID as the primary way of authenticating users unnecessarily complicates the UI. Offering it as an option, especially the dynamic way Intense Debate does it, can work well. Using one of the other authentication systems when you're not trying to get data from that third party will just confuse the user. Why is this random website trying to sign me into Yahoo?
Just plain-old username and password. Before launch I'll experiment with running everything over SSL, but it might turn out to be too much overhead for a bunch of tiny AJAX requests. If so, then I'll keep the session in cleartext but do secure login by implementing DH key exchange in JS.
Shock! Horror! Diffie-hellman in javascript is a really bad idea. Javascript would be unbearably slow for the size numbers you'd have to work with for a good implementation of DH, if it could even represent numbers that large. From http://www.howtocreate.co.uk/tutorials/javascript/security:
"The problem is that in order to prevent brute force cracking techniques, these require the browser to handle numbers as high as 2x10^600 or higher. JavaScript is just not natively capable of working with numbers as high as this."
Why reinvent a great and secure technology like SSL? The overhead of SSL would pale in comparison to rolling your own DH in JS.
Why reinvent a great and secure technology like SSL? The overhead of SSL would pale in comparison to rolling your own DH in JS.
> JavaScript is just not natively capable of working with numbers as high as this.
Implementing multiple-precision multiplication is hardly rocket science.
> Why reinvent a great and secure technology like SSL? The overhead of SSL would pale in comparison to rolling your own DH in JS.
I'm not trying to reinvent it. I'm just trying to make a very lightweight alternative for protecting your password and nothing else. The DH in JS would just be just be run once when you logged in, not for the entire session like I'd like to do with SSL. Obviously SSL is preferable if it works.
Implementing multiple-precision multiplication is hardly rocket science.
> Why reinvent a great and secure technology like SSL? The overhead of SSL would pale in comparison to rolling your own DH in JS.
I'm not trying to reinvent it. I'm just trying to make a very lightweight alternative for protecting your password and nothing else. The DH in JS would just be just be run once when you logged in, not for the entire session like I'd like to do with SSL. Obviously SSL is preferable if it works.
Not only that, but to implement diffie-hellman key agreement correctly you have to authenticate the exchange in some way. This is usually done with cryptographic signatures and that means implementing at least one other number theory algorithm with even more slow big integer exponentiation.
DH without authentication still fends off a large class of attackers. Spoofing IPs is hard. Typing 'tcpdump' is easy.
We use Django as well. Plus, authentication is sort of inherent in our startup by its very nature, so even that isn't needed. I couldn't really say more than that, but if I explained it, you'd understand.
i suggest you wait till Thursday to see what OpenSocial has to offer.
OpenID