Ask HN: Which login method do you use?

https://news.ycombinator.com/item?id=575927

by apstuff • 17 years ago

20 56 17 years ago

news.ycombinator.com

I'm at the point where I need to implement login capability on my main page.

What method do you use? php with a database? cgi against a protected file? Clickpass.com like HN.

Or did you roll your own?

mk• 17 years ago

django.contrib.auth

jmtame2• 17 years ago

I have always created my own. Although I've been doing PHP, I'm currently using RoR and it has a plugin that handles all of this. PHP with a database is very easy, especially if you use CodeIgniter, there are form validation helper classes.

On registration:

- Ask for username and password (do form validation, ie passwords match, xss clean, etc). toLowercase() the login.

- Create a hash of some type for the password. This becomes used in the database, and again on login. If you're not worried about security, md5 your password, store it in the db. Otherwise, look up a salt hash.

- I typically log the user out and then require them to log in and create a session after they registered.

On login

- Ask for username and password, toLowercase() the login when checking

- Run the same md5 or salt hash against the password, check if the # of rows in the database is > 0, if it is, log the person in and give them a session with a value of "is_logged_in" to true or something similar. Also pull the database user_id or e-mail and use that to remember which user you're dealing with.

- If the # of rows found in database is == 0 (where the login and pass equal those from your post variables), the login failed

tptacek17• 17 years ago

Please don't just use MD5 or SHA1 with a salt.

http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...

siong19872• 17 years ago

Rainbow Table is unavoidable. Block those IPs which have more than certain times of failed password. And, people usually cannot access to those hashed passwords.

thorax2• 17 years ago

I upvoted you because that's a good link and good advice in a sense. I don't agree fully with your exact phrasing and would put it a bit milder for someone asking this kind of question.

I'd personally advise: Use a respected library or at least an MD5 or SHA1 approach with a strong salt. There are better ways that you should consider (link), especially if you're writing an authentication package for reuse by others.

modoc• 17 years ago

I have my own code I use on my projects. It uses secure SHA 256 hashing for the passwords. The code handles registration, login, logout, and forgot password flows.

e1ven• 17 years ago

We pass the login and passwords to an openldap server running internally, and then get back the success/fail message.

This is the best strategy for us because it allows us to offer a wide array of services running through our accounts, using out of the box software..

We can tie the forums into LDAP without writing our own, as well as our internal Jabber server, etc.

Once login has completed, we give the user a 128-bit sessionID, which we use for all further communication, until their session expires.

Confusion• 17 years ago

As opposed to insecure SHA 256 hashing?

Anyway, if you don't use a nonce per user or a time consuming hashing method, then all tptacek's comments apply. His link in http://news.ycombinator.com/item?id=576021 is worth your time.

zmonteca• 17 years ago

We used a combination of Cake Auth

javanix• 17 years ago

I am working rolling my own with Struts/JSP.

It seems pretty straightforward (hash pass, place on server, and check against), but I need an easy way to compute an SHA hash in-browser, so the server doesn't have to receive the pass in plaintext.

Anyone know of a way to do it with Struts/JSP, or even JS if its not too slow?

tptacek17• 17 years ago

This is kind of silly:

* The hash you send will probably be password-equivalent; losing it to an attacker is just as bad as losing the password.

* If you're delivering the JS to generate the hash over HTTP, you have exactly the same threat model as with plaintext passwords (attackers will just subst a script that sends the raw password).

* If you have working HTTPS, you already have optimal communications security; just send the password.

* Even if you came up with a challenge-response protocol to make the hash non-replayable, the exchange itself would be vulnerable to a trivial dictionary attack.

Don't bother with this idea. Move on to something that will add real value to your app.

dmanxiii• 17 years ago

OpenID, if applicable.

frossie• 17 years ago

Comment from the user end: I am not the greatest fan of OpenID (try talking your grandma through getting one) but I agree that as long as you don't have a site where the user might have a real need for unique authentication information (eg. bank account), you should really consider something like clickpass.

I always try new sites if I can get in with existing authentication - and I don't always if I need to register. So it depends how much you care about uptake.

tptacek17• 17 years ago

Most every web application my team assesses just uses a database of hashes. This is fine; just try to make the hash function take a long time to run (speed is the enemy here). I highly recommend "bcrypt", a routine available in almost every dev environment --- and typically in the better plugins --- for generating safe auth hashes.

SemperUbi• 17 years ago

HTTP Basic + https

lsc11• 17 years ago

how come you don't use http digest? http://en.wikipedia.org/wiki/Digest_access_authentication it is significantly more secure without https

tptacek17• 17 years ago

Because digest requires you to store the plaintext of the password on the server, making any database or filesystem exposure a calamity for all your users.

dryicerx3• 17 years ago

Since most people already talk about the backend of it, let me share how to securely send the password from the browser to the server encrypted, instead of simply in clear text. (when you can't use SSL for some reason)

+ Server has your passwords stored as sha1(password+salt(password)). salt function isn't secret (eg. reverse the text)

- Client visits login page

- Website generates random token. Then sends back HTML with the random token

- Client generates passresponse = sha1(token + sha1(password + salt(password)))

- Client sends the passresponse, token, and username back

- Website checks for existence of token, removes it, then computes it's own sha1(token + password_hash_from_db) and checks against the sent passresponse.

This way the password is never sent in clear text. Unlike HTTP authentication, this works nicely with html forms since you can do all the crypt in js. Then again, this might be a bit overkill... and using SSL is probably a better option.

Just sharing another solution.

tptacek17• 17 years ago

You're describing the simplest possible challenge-response scheme. It has two problems, both severe enough that you shouldn't recommend people waste time implementing it:

* First, because no browser bakes this crypto protocol in, you have to deliver it over Javascript. The protocol basically stipulates that you don't have SSL/TLS. So all you've done is move the goalposts. No matter what kind of dance you do (for instance: Meebo actually delivers a JS implementation of RSA!), the action is now in the JS delivery, which is trivially compromised.

* Second, secure authentication schemes aren't vulnerable to trivial dictionary attacks. This one is: the attacker is stipulated to have access to your traffic. She sees the nonce the server sends and the hash the client responds with. She can solve for the password by (very fast) brute force against a wordlist.

dryicerx3• 17 years ago

To your first point, yes js would be doing the crypt, if the js delivery can be compromised, then the login html delivery can be equally compromised (which would send the login information somewhere else)

I agree with your second point, a eavesdropped can use a dictionary attack. It makes it just a tiny bit harder for them since they need to generate their own cleartext-crypttext and cannot use a pregenerated table.

I am curious, is there a better way to do this (other than SSL or using RSA)

lsc11• 17 years ago

sure sounds like you've re-implemented http digest authentication.

http://en.wikipedia.org/wiki/Digest_access_authentication

dryicerx3• 17 years ago

That's what I had been using earlier, problem with that is the ugly login box the browsers prompt (there is no way to integrate HTTP Authentication in to HTML)

lsc11• 17 years ago

I use http auth

apache has modules to hook it up to just about any backend; it's supported by all browsers, and it's easy to automate against.

I would be interested in knowing why more people don't use it.

tptacek17• 17 years ago

Because, at least with mainstream browsers, users can't log out.

You can fail certain formal security audits for using HTTP authentication.

lsc11• 17 years ago

Speaking of the audit problem, do you have a link? is this just for http basic? or is this the case for http digest as well? what about negotiateAuth with mod_auth_kerberos or the like? is this only because of the logout problem? or because of the problems with basic auth?

hm. I know you can logout by going to https://username:boguspassword@thesiteyouarelogingoutfrom.co... but that will ask you to re-input your password, usually, making it unsuitable for a 'logout' button usually, I think. I wonder if there is a js workaround for that.

rguzman• 17 years ago

facebook connect

coopr• 17 years ago

Anyone have any pros or cons of Facebook Connect? Besides the obvious con of requiring your users to be Facebook users too?

rincewind• 17 years ago

ssl client certificates

tptacek17• 17 years ago

I can't understand why making SSL client certs a totally seamless experience for end-users isn't the #1 security priotity for the IE and Firefox teams.

kineticac2• 17 years ago

We're using Rails as the framework and restful_authentication plugin for logins. Moving forward we are also going to integrate OAuth for things like Twitter logins, Facebook Connect for facebook, etc.

matticakes• 17 years ago

http://www.openwall.com/phpass/

kineticac2• 17 years ago

Just put the TwitterAuth gem into my rails app, and am using OAuth with twitter now. This is a niche though, meaning unless you already have twitter, or actually like it, it's a long process and could keep people from signing up. Logging in is easy though.

http://kineticac.posterous.com/rails-and-twitter-signin

Ask HN: Which login method do you use?

Related Stories