views:

82

answers:

4

I'm developing a small website where I'm going to allow user to create accounts but I'm quite clueless when it comes to safety around authorizations.

I have built my project in PHP with codeigniter and found a library (Tank Auth) that could handle authorization for me. It stores password in a safe way but I'm still worried about the part when the user sends their password to my server.

One easy way to do it would be to send the password in a post-request but I would guess that it's quite easy to sniff such a password. Should I do something with the password on the client side before sending it to my server? And is there any good javascript libraries for this?

+1  A: 

You can muck around with client-side hashing, but in general POSTing the credentials over a secure (HTTPS) connection is considered sufficient.

This still leaves the possibility of MITM attacks… But performing an MITM attack on an SSL connection isn't entirely trivial, so it's probably not an attack vector you need to be too concerned with.

David Wolever
Ok, well SSL is a little bit to expensive for my pure hobby project. Would you guys consider me to have bad security if I sent passwords in plain text between client and server or is it ok to do it like this on smaller websites?
Irro
@Irro: I would only do that on websites where the accounts don't really matter and only if you tell your users that the passwords aren't secure and that they should use a unique password for your site. Some users tend to use the same password for everything and that's only as secure as the most-easily crackable place you use it.If one of those conditions are false for you and SSL is too expensive, you're kind of stuck on client-side encrypting, and that adds a bit of complexity to authentication and has security issues of its own.
Shaun
Yes, it is bad security… But if it's just a hobby project it might not matter. I wouldn't be too bothered when I notice that a hobby site I use doesn't use SSL (but that's mostly because I use a different password for each site).
David Wolever
@David Wotever: Not everyone is as concientious and technically savvy as you.
symcbean
A: 

Authentication via SSL is probably the easiest and most secure way.

If you encrypt it in something like rot13 etc.. it's easily undoable.

As mentioned also, you would want to make sure that your website's security isn't relying on Javascript as that can easily be turned off.

Any other operations performed on the client side can easily be broken.

Cetra
It isn't true that client-side operations can be easily broken. It is possible to do proper client-side hashing which does result in a fairly secure system: if the server sends a [nonce](http://en.wikipedia.org/wiki/Nonce) and the client responds with `H(nonce + password)`, then replay attacks are impossible and it's "hard" to recover the password.
David Wolever
As I mention in the other comment, SSL is a bit to expensive to me. do you think it ok for small web pages to send password in plain text? How does other non-SSL web pages handel it?
Irro
If I am listening into a conversation between client and server, not only do I have the nonce, I also have the output of the nonce+password.I then don't have to involve either parties to break the password. All I need to do is perform a dictionary attack or brute force it, but I still have the password.What happens when javascript is turned off also?I don't consider using a nonce as a secure method of authentication.
Cetra
See my comment above re. not using SSL. Some pages will use client-side hashing, which is better than nothing… But, unfortunately, most pages just don't do anything.
David Wolever
http://code.google.com/p/repoze-who-jscrypto/ might be good to look at.
David Wolever
@Cetra: the nonce serves two purposes: one is to act as a form of salt… But, as you've correctly noted, salts only make hashes more resistant to mass-cracking, not individual cracking. The real purpose of the nonce, though, is to prevent replay attacks. It means that an attacker can't re-use the value `H(nonce + password)` at some point in the future.
David Wolever
+1  A: 

You say that SSL is too expensive for you, but most hosts offer it for free. The expensive part is getting a private IP address and formal certificate.

However, you could create your own certificate which would mean that all the details are still transmitted securely, it's just your identity that can't be guaranteed. As mentioned by David Wolever, MITM attacks are much harder to do; and anyway are probably not a concern for a hobby site.

Once (if) your site evolves out of being a hobby then you can invest in an assured certificate then.

Kurucu
+2  A: 

As others have said SSL is the prefered way to go.

David Wotever metioned hashing - there's a detailled discussion of the process here

An alternative approach would be to rely exclusively on external providers to handle your authentication for you - openid being the most obvious candidate.

HTH

C.

symcbean
That's a nice discussion of the hashing process. Also, +1 for OpenID. Very good call.
David Wolever