Not planned Login security: sending passwords over the channel - two stage authentication

[Timothy Kaler]

Currently passwords are being sent as typed by the user. A better strategy would be to have a two stage login process. First the user enters their username and password and presses "login." Then the user's username is posted to the server, and the server generates a random handshake string. This handshake string is returned to the user, and the server remembers that it assigned this specific handshake string to this user's username. Then the user's password is concatenated with the handshake string, and then a hash function is applied to generate an authentication string. Then this authentication string is posted to the server.

A little convoluted, but its super easy to implement. It doesn't give a site the same security as sending passwords over an encrypted connection, but it is pretty good.

~Tim

 

[jmurrayhead]

Or...have support for SSL

 

[Timothy Kaler]

SSL is the obvious solution for sites which are serious about security.

~Tim

 

[Koleckai]

Much easier to just hash the password via javascript. Hash it with a session token and/or an admin defined sitekey before sending it. No need for the back and forth.

 

[Timothy Kaler]

Doing it with a session token is the same as what I proposed, just the handshake string would be the session token generated for the user at a different point in time. Using a site key is not a good solution, because if the user always sends the same authentication string to the server when they login, then a password sniffer could obtain that string to compromise the user's forum account.

~Tim

 

[Koleckai]

It only protects against tcp/ip traffic sniffing anyway. If the user has a sniffer on the PC then nothing will protect the login information except RSA Token technology. If your worried about tcp/ip traffic sniffing, you should be under SSL.

 

[Timothy Kaler]

It only protects against tcp/ip traffic sniffing anyway. If the user has a sniffer on the PC then nothing will protect the login information except RSA Token technology. If your worried about tcp/ip traffic sniffing, you should be under SSL.

If the user has a keylogger on their computer, then nothing will protect them. However, if the user has a program that is monitoring their network traffic, then all of the security precautions meant to prevent channel attacks would also serve to protect the user with the locally installed network monitor.

Without a doubt: SSL is the most correct solution to this kind of security problem.



~Tim

 

[Erik]

Just keep in mind that good SSL certificates are expensive. While I certainly agree it's the best solution, it's not accessible for everybody. SSL login support would be great though!

Of course, there's nothing stopping you from getting a cheap SSL certificate. Most users won't even know the difference.

 

[Floris]

I recommend to take a look at the cookie by xenforo.com in your browser

 

[Enigma]

I don't think we're talking about cookies. It looks like when logging in, passwords are sent in plain text.

 

[Erik]

I recommend to take a look at the cookie by xenforo.com in your browser

Not sure what I'm supposed to be looking at honestly.

 

[Timothy Kaler]

Passwords are still being sent as plain text. You should consider the two stage authentication scheme I proposed. It provides good login security without SSL.

Tim

 

[Adam Howard]

For security some kind of 2 step verification log-in would be idea for (Super) Administrators.

(You could of course expand on this, but I think Admins would be good enough)

 

[Hornstar]

For security some kind of 2 step verification log-in would be idea for (Super) Administrators.

(You could of course expand on this, but I think Admins would be good enough)

I agree. Personally I would like this to be a 6 digit pin that you have to enter in with your mouse. The digits displayed on the screen would be in random order too.

As you can see above, the digts 0 -9 are in random order. Every time you refresh the page, the digits are in a different order. You can only enter the digits with your mouse.

 

[Biker]

Anything entered via mouse click or keyboard can be read by keyloggers. 2 factor authentication would have to be totally separate from each other. Like using your cell phone and computer.

As such, I don't see this going very far.

 

[Ingenious]

Anything entered via mouse click or keyboard can be read by keyloggers.

The digits in Hornstar's example are in random places each time to mitigate this.

 

[Hornstar]

The digits in Hornstar's example are in random places each time to mitigate this.

Yep, that's correct. It is a huge step in solving keyloggers. Is it 100% foolproof? probably not, however it is a huge step forward.

 

[Biker]

The Chinese gold farmers have been combining screen shots with their key loggers for years to steal gaming accounts. Random placement doesn't work.

 

[digitalpoint]

Two-factor authentication would be better than "two-step"... Two-factor is a secondary *factor*... first factor would be you know your login/password... 2nd factor being you have physical possession of an object (like your cell phone). See this thread for more info: http://xenforo.com/community/threads/two-factor-authentication.22845/

Then it doesn't matter even if someone knows your login/password, because chances are they don't have physical possession of your device.

 

[sonnb]

This is possible to make an 2-steps verification like Google that requires users to enter the code sent via SMS to complete the login.