secure login without SSL

[deller]

I was wondering how it would be possible to make a registration/login system that is secure without using SSL.

(Im doing this for learning. If you want to tell me to use SSL, please dont comment. I already know i should use this for high security systems.)

First, i would like to say that im no expert. Feel free to call me out on bad assumptions i make. Im just trying to learn the ropes to basic security.

I want my system to be basically immune to everything but man in the middle attacks (which as i understand only SSL can prevent).

I think i have part of the login down so far:

Client Server
<------ random string (salt)
1)hash pass with salt
2)username +
hashed salt and pass ------> 1)hash known password for
user with salt
2)compare client hash and server hash
3)if equal
<------ "ACCESS"
else
<------ "NO ACCESS"


problems with this:
username is sent in plain text. This allows for a sniffer to get user activity info. Not critically important, but would be nice to find a fix.

Bigger problem with this:
Registration will require to send the username and password in plaintext.
I thought about hashing the password upon registration and comparing client's hash(hash(plainPass)+salt) and server's hash(storedPassHash+salt).

This is still vulnerable to a sniffer, who could get the password hash upon registration. Then, he could go to login, get the salt, send hash(sniffedHash+salt) and login just fine.

Will using RSA on registration prevent this completely? If so, where is there a good implementation?

How do i solve those problems?
Are there more problems with my system?
I know i will always be vulnerable to man in the middle attacks without SSL, but what else am i vulnerable to using this?

Im assuming trustworthy admins for now (they wont sell password hashes or plaintext passwords), but if you have a fix that allows for less trustworthy admins, it would be appreciated.

Also, what is your take on sending passwords by email?
secure, insecure, depends?

Looking forward to comments.

[deller]

145 views, no comments. Someone want to help me out?

[iansane6]

How bout some novice suggestions since no one has responded?

Something I was reading one day suggested getting any info you can think of that is not going to change such as the user agent and adding that into a hash and then storing it on the users browser as a cookie to help prevent session hijacking. Many comments said SSL and the writer of the article was trying to tell people that everything you can do is an extra measure of protection so he was trying to tell people what to do in conjunction with SSL but many people wanted to argue.

Another thought. What about javascript so the username and password are encrypted on the users browser before ever being sent to the server? If you know the algorithm you use then you can recreate the same encryption on the server side to compare strings when authenticating. Of course this only works when javascript is enabled and assuming the users browser isn't already hijacked and keylogging every thing the user types by a trojan or virus but the same could be true for SSL connection so that part is up to the individual user.

Actually now I'm wondering if the entire session could be encrypted on the users end and decrypted on the server for any communications which would take out SSL, still accomplish an encrypted connection like SSL and be forced on the end user by the fact that it is javascript working on there end.

Eh, just random thoughts. Sorry if they are no help.

[deller]

Yea, actually, i when i wrote this, i was really looking for an RSA solution. I actually found one now.
Its pretty amazing how long it took! i would think people are more interested in security.

Basically, server sends pub key to client, client encrypts AES key with RSA pub key and encrypts data (user and pass) with AES, and sends over to server. Server decrypts AES key with RSA priv key, and then decrypts data with AES key.

Pretty much classic SSL without a certificate, so its still vulnerable to man in the middle attacks (let me know if you want an explanation), but to be honest, those take a TON of skill and money and time, and i dont think someone is going try it on my server.

Let me know if you want a copy of the system

[criterion9]

Yea, actually, i when i wrote this, i was really looking for an RSA solution. I actually found one now.
Its pretty amazing how long it took! i would think people are more interested in security.

Basically, server sends pub key to client, client encrypts AES key with RSA pub key and encrypts data (user and pass) with AES, and sends over to server. Server decrypts AES key with RSA priv key, and then decrypts data with AES key.

Pretty much classic SSL without a certificate, so its still vulnerable to man in the middle attacks (let me know if you want an explanation), but to be honest, those take a TON of skill and money and time, and i dont think someone is going try it on my server.

Let me know if you want a copy of the system

They may not specifically target your server.... but they could target one of your users. SSL is the way to go.

[iansane6]

So, basically you have something similar to public key encryption like pgp but without the use of a 3rd party key authority?

What if there is a piece of data known only to your server and only able to be decrypted by the end user that proves it is the actual server and not a man in the middle? Would that protect against mim attacks?

I've always been confused as to how a ssl cert can prove with 100% certainty that the server you are communicating with is not a mim server. Or maybe I am misunderstanding how mim works. Maybe I've been associating mim attacks with simple packet sniffing. Does a mim attack basically act as a relay between the user and the real server so as not to be detected while all the while, collecting the users information? So even if mim is possible with your solution, the data collected would all be encrypted with a key that the mim server doesn't have?

[deller]

Man in the middle works like this:
client=Alice
server=Bob
hacker = Mal


-Alice sends a packet asking for Bob's public key.
-Mal intercepts that packet, and sends its own request for Bob's key.
-Bob got Mal's packet, but not Alice's packet.
-Bob sends Mal his public key.
-Mal saves Bob's public key.
-Mal generates a priv/pub key pair and sends Alice that pub key.
-Alice thinks the key she got was Bob's, but it is really Mal's.
-Alice encrypts her secret data with Mal's public key and sends it back.
-Mal intercepts the packet, decrypts with her own private key, optionally changes the plaintext data, encrypts it with Bob's public key, and sends it back to Bob.
-If Mal changed the plaintext, she might cause Bob to do something he thought Alice told him to do or if she didnt, neither Bob nor Alice would ever know that Mal had intercepted the secret data.

In a MIM attack the hacker needs to have complete control over the communication channel.

If both parties had the same key, yes it would be secure. The problem lies in the key exchange - how do both parties get this key?
Remember that the attacker has control over what you send. You would need to trade this key offline or something.
Pub/priv key encryptions lets you do secure key exchange only if the channel is not controlled by hacker (which cant be guaranteed).


In ANY system, the hacker can collect the encrypted data, although in secure systems, he cannot decrypt.


What i have IS pub key encryption, not like it. RSA (arguably the best known pub key algorithm) for key exchange and AES (good symmetric key encryption) for data exchange.

My system does not protect against MIM attacks, but i figure they take so much skill and resources (to completely and definitively take over the communication channel) that its almost not worth it to protect against it in non bank/ecommerce/high value secrets situations.

Sorry if im not clear or if its too simple - i dont know how much you already know, feel free to ask any questions.

[iansane6]

Thank you deller for that detailed and understandable explanation.

I was confused as to the exact method used by the mim attack and I remember messing with pgp a couple years ago for encrypted email. There was a public key authority where my friends client would retrieve the public key but if I remember correctly we did have to each send the other our private key. In a learning situation this is ok but in reality the private key exchange would need to occur over another encrypted channel or physically such as handing over a disk or usb drive with the private key.

I went over all this a couple years ago and even took a couple of security classes in college but by not practicing it I forgot exactly how it all works.