4

As my webserver doesn't allow use of the PHP_AUTH_USER and PHP_AUTH_PW keywords because of CGI (Col. Shrapnel in 'PHP_AUTH_USER not set?') I'm examining some other ways to send a user's password to the server.

Sending the password as plaintext using POST is a no go: capturing packets and looking at the header reveals the password. So I could hash the password first. But someone intercepting the packet and copying the hash and username could still login using this information, right?

Making the hash dynamic by using a timestamp could prevent copying the hash. Sending the password as (timestamp + hash(password+timestamp)) (Last.FM uses something like this). The server could then subtract the timestamp (check if it's not expired or something), and hash the known password with it and check if they are the same. But then the password has to be known by the server, so the question remains:

how to get this password safely to the server upon registering?

Then, there's https, requiring a SSL certificate, which is not available for me (not worth the money (yet?)).

Any thoughts?

p.s. In the end I want to authenticate an Android app against my webserver

Community
  • 1
  • 1
nhaarman
  • 98,571
  • 55
  • 246
  • 278
  • 4
    There's free ssl certificates, and if you don't mind the errors that browsers spit out on self-signed certs, you can always make your own. – Marc B Jan 31 '12 at 18:35
  • That changes things. I'll have a look into that. – nhaarman Jan 31 '12 at 18:50
  • Self-signed certs. There won't be rejection because it's not up to the user but to your server and your client. Also, hashing and adding timestamp could do... – Alfabravo Jan 31 '12 at 19:05
  • Why do you need the password on the server side? The password should be safe for you and your users. You should save the encoded password and compare encoded values without reading the real password. That´s a safe way for users. So, the timestamp solution can be valid for sending the password to server. – Rodrigo.C Jan 31 '12 at 18:46
  • Client will append the password with the timestamp, and hash that. Then append the timestamp again. The server will subtract the timestamp, and append it to the password that it has stored in a database. Hash it, and check if the results are equal. (Where I say password, I could also say a hash of the password). Also this would be better off as a comment. – nhaarman Jan 31 '12 at 18:48
  • Any thoughts still on how to get the password safely to the server upon registering (without ssl)? As I can't use the timestamp method there.. – nhaarman Jan 31 '12 at 21:04

2 Answers2

1

Where I've needed that level of security for data sent to the server I've used a similar system, hashing the data with a fixed-length client-derived key, appending, prepending or interleaving that key and converting the resulting string to hex. In theory the string could be decoded if intercepted, but realistically you'd need at least some idea of the schema used to derive the key.

SourceMaid
  • 473
  • 3
  • 6
  • But there is still the 'base' password that needs to be exchanged where both sides can hash on. How would I do that safely? – nhaarman Jan 31 '12 at 19:31
  • 1
    If you do this method, make sure to obfuscate your code! It's scary how readable the code is when you disassemble your apk. – William Melani Jan 31 '12 at 19:46
  • @Niek: there's no absolute safety in any security mechanism. The solution needs to be proportionate to the risk. – SourceMaid Feb 02 '12 at 19:20
0

If security really is so important to you, I'd really go for something like HTTPS. If it's not available to you, maybe switch webhost or whatever is your limitation? If money is the problem, there were some suggestions in the question comments (free ones, self-signed, etc).

This hashing with timestamp and such is pretty much only going to end up as security through obscurity (related question).

I'm not a security expert though. All I know is that security is very very hard, and the ones who want to break in are usually smarter than me. So I try to keep things simple and use common well-tested solutions instead of trying to come up with my own "clever" thing.

Community
  • 1
  • 1
Svish
  • 152,914
  • 173
  • 462
  • 620