What is the best way of securing a website logon without SSL or preshared keys?

Question

Today I sniffed some unencrypted wlan traffic during class and I found quite a few passwords by a simple search for "pass" and "user" in wireshark. Turns out about half the sites we use for school don't encrypt their data in any way - they use GET-requests like ?username=user123&password=passwd123 on login. I started to think about this and now I wonder; what is the best way to avoid this? Encrypting would be easy to reverse, and one time keys could "easily" be captured as well. My best thought so far is to client side hash, but would this be a bad idea in some way?

UPDATE: I've obviously not told you the constraints here, but thanks for all the answers! The server does not have SSL and everything I use must be implemented in php/asp/asp.net server side or javascript on the client. The only preshared key there is is the password. Everything else will be known to the attacker.

I'm only trying to hide the password from the hacker. The rest of the information would be unencrypted, so a session steal would be possible. That will be the next problem. Maybe you could encrypt the information on the page with the nounce. Since there will be a lot of encrypted text a dictionary attack would be effective. This is why I don't want to use the user's password for encryption. Maybe I could use something like a 512/1024bit XOR key that I encrypt with the user's password? Or some part of the password, since a dictionary attack would still be possible - but harder.

Would a nounce encrypted with the clients say 2 first chars of his/her password be a good idea? A random number XOR'd with the passwords 2 first chars. This should be decryptable by the user, since he/she has the key (which would be taken from the entered password string through js). The nounce would be a random number, so nothing should be able to tell if it's been correctly decrypted.

Basically: 1. User types in username and posts/gets it to the server. 2. Server responds with a page with an encrypted nounce and a password box. 3. Javascript decrypts nounce, and password gets XOR'd with it. 4. Password is sent to the server, password gets decrypted and then hashed 5. Hash is compared to a stored one in the database.

Note: The server is free and it supports SSL, but I don't want to use it. I don't like SSL because it's broken.

Answer 1

You want the target server to be able to access the user name and password, and not the sniffer-powered attacker. So the target server must be able to do something that the attacker cannot. Since the attacker can buy the same kind of PC than the server, that extra power must be something that the server knows, but not the attacker.

Hey, there is such data: the password ! That's the point, isn't it ? It really is a pre-shared key between client and server.

Passwords are pretty lousy, as far as key go, because of the limitations of human brains. Still, one can work with that. The best protocols for that are Password Authenticated Key Exchange: they can escalate a shared low-entropy key (the password) into a shared high-entropy key, with which you can do all the yummy stuff of symmetric cryptography, which will keep (wire)sharks at bay. And PAKE protocols can do that while resisting offline dictionary attacks ("offline" is the important word here).

The bad news is that PAKE protocols, and, more generally, any authentication protocol which can be linked afterwards with exchanged data so that the authentication really resists active attacker, are difficult to get right. The simplest but still secure protocol turns out to be SSL with SRP (there is an RFC for that). The good news is that SSL+SRP provides password-based mutual authentication between client and server using no certificate whatsoever (and when people say that they do not want to use SSL, what they usually mean is that they do not want to dabble in X.509 certificates and the friggin' PKI market).

Unfortunately, SSL+SRP support is not widespread (GnuTLS is an opensource library which knows SRP).

Answer 2

if you use client side hash then it become actual site password and you didn't achieve anything.

Answer 3

The best way is to use SSL. The mechanism exists for a reason. Alternative schemes tend to be either insecure or insanely complex.

You said you wanted to do it without using SSL, but you gave no reasons or rationale why. You didn't explain the situation you are in or what would justify avoiding SSL. Consequently, even if we wanted to provide you some alternate suggestions, it would be impossible to determine whether they meet your requirements.

Answer 4

If all you are interested in is authenticating the user to the server (and don't care about encrypting later data), Lamport's Hash would be easy to implement as there are already hash function libraries implemented in Javascript and PHP/ASP/ASP.net.

Lamport's Hash is a type of one-time password scheme that works as follows (Alice is the user, Bob is the server):

Initial Registration

Upon registration, Alice sends [n,hash^n(password)] to the server (where hash^n is the result of hashing the password, then hashing the result of that, then hashing the result of that, ..., n times). The server stores [n,hash^n(password)] in the database.

Authentication

1. Alice sends her ID (username) to Bob: "Alice"
2. Bob responds with "n"
3. Alice sends x=hash^{n-1}(password) to Bob
4. Bob compares hash(x) with the digest stored in his database
   • If they match, authentication is successful and Bob replaces [n,hash^n(password)] with [n-1,x=hash^{n-1}(password)]
   • Otherwise, authentication fails and Bob retains what is in the database

Practical Considerations

• You will most likely want to use a salt with the password (Bob can send the salt in #2)
• Once n is small enough, Alice will have to change her password (or they can just change the salt), and she will have to re-send [n,hash^n(salt+password)] to Bob
• Choose n large enough so that the reregistration isn't too often
• Since this is only a one way authentiation (user is authenticated to server, but server not authenticated to user), man-in-the-middle is possible.

If Lamport's Hash doesn't meet your requirements (e.g. you need mutual authentication), SRP is probably your best bet, but by the time you have implemented it in Javascript and PHP/ASP/ASP.net, you could have rented a server which supports SSL which is clearly the best choice from the beginning.

Answer 5

The answer is TLS (not even SSL) without AES as the encryption algorithm, since there is a known issue with the combination of TLS, AES and WebSockets for example. Everything else (like encrypting the password in the client using javascript) is insecure. Of course, it cannot be read direcly using wireshark but the javascript may come from a man in the middle. so try to convince your school? to switch to TLS servers. This is the easiest way and it will not require any change of application code.

Answer 6

SSL cannot be as broken as clear text passwords. Use SSL. I think that Scheier has something to say about people who design their own cryptosystems.

Answer 7

I don't like SSL because it's broken.

That's a rather dramatic claim to throw out without any explanation nor supporting references. Do you mean all forms of SSL including TLS or specifically SSL v1-3?

It's a lot better than a lot of other attempted solutions to the problem.

The only way to establish secure communication is via encryption - and for a browser based client, if you're not using the builtin functionality of SSL, then you're delivering the code to implement the encryption (be it Javascript, activex, java, flash....) over an unsecured connection. Hence the code can be compromised. It doesn't matter if you use rot13 or a 4096 bit key with a PFS algorithm - if it's handled by code delivered insecurely then modifying the code to capture the password is easy.

If you think SSL is broken, then fix it - it's a much more profitable way to spend your time.

Answer 8

If you can run JavaScript on the client, you could setup a Diffie-Hellman key exchange or a challenge / response mechanism based on the password's hash (don't store plaintext on your system!) and use that to do a fancy authentication process where an encrypted credential is returned for authentication.

Those won't stop active MITM attacks, but it will keep passive attackers from sniffing passwords.

Answer 9

First thing I'd check is if the server supports http authentication with digest authentication. You might be able to enable it via php.

http://www.php.net/manual/en/features.http-auth.php

It's not nearly as secure as SSL, but it could be a simple trick to keep people in your class from swiping your passwords. Use http auth to block the area of the site you need to protect. They'll see everything you're doing, but they won't get the http authentication password. (they will get any other password inside the session)