Secure data transfer to server

[keyboard]

When using <input type="password"> it says never to enter secure data because it isn't encrypted. I'd call passwords secure data, so should we be encrypting them with... Javascript? before sending them to the server, then un-encrypting them with php?

[ApacheTech]

There are a few options.

Encrypted
The most obvious is to encrypt them in the database, either with AES or MD5 or your chosen favourite algorithm. When you submit your form, you encrypt the password and send that, checking with the database on arrival that the hashes match.

This does add one problem, users will not be able to recover their passwords. They will have to reset their password and be sent a new default password to continue.

For added security, you can "salt" the hashes, providing added protection from the regular rainbow table attacks available online.

Encoded
Encoded passwords are more security through obscurity than anything else. The simplest method is to convert the password to Base64. This method isn't particuarly safe, but it will stop the most basic of password sniffers. To increase the security, include your own algorithm. I tend to use a combination of ROT13, ROT95 and Base64 to create a unique bespoke algorithm.

Encoding your passwords is not as safe as encrypting your passwords because once the would be attacker has the password string, there is still a way, through brute force and trial and error that the password can be decoded.

Encoded passwords can be recovered by the users, as the plaintext password is available to be decoded.

SSL
Using an openSSL certificate will allow your application to use the least amount of internal encryption/encoding, because the packets sent to and from the server themselves are encrypted, using a two way, or sometimes four way handshake.

That said however, an attacker using a man in the middle attack such as Jasager or any other Karma based device (WiFi-Pineapple) could easily circumvent this by using a payload such as SSLStrip. At this point, the security is down to the user, and their knowledge of internet security flaws. The average user won't even think to check if they're still connected via HTTPS before pressing submit.

For the greatest protection, use a combination of all three methods.

All server and admin passwords should be to cryptographic strength. You can use this resource to create such passwords:

https://www.grc.com/passwords.htm

As a very short case study between cryptographic methods, take the difference between WEP and WPA with wireless router network keys. An 8 digit password in WEP would take, at most, a few days to crack (brute force), but may equally take only minutes. The same password in WPA, being cracked by the same computer would take as a minimum time, longer than from the Big Bang to now.

[traq]

there is very little point to encrypting/encoding a user's password clientside (before submitting the form). Yes, no one will be able to sniff the password and then type it into your login form - but who does that? No one. They sniff the password, then login using whatever value they sniffed. Your server will never know the difference.

You might look at something like Digest authentication. It is very widely supported, uses nonce values, and the password is never sent in plain text. However, it relies on the password being pre-shared: which means you'll end up sending it in plain text at least once, more if you allow users to change their passwords on the site.

Realistically, as Apache suggests, the only decent solution to this problem is to get an SSL certificate and use https.

[ApacheTech]

The other option of course, is to authenticate the user on the same page, before the form is submitted and only submit the result (Whether the login was successful or not) to the form's action page, maybe a checksum that can be used to authenticate the submission.

One other thing, just remember that as the Web Developer, you are only partially responsible for the Information Security of your site. The end user is just as responsible in making sure that sensitive information is not leaked.

Remind your clients of the following:

• Always make sure that if you are supposed to be using a secure connection which requires SSL, that the URL you are viewing starts with the prefix "https://". This is vital. If you have accepted a certificate and you are using a site that says it is using SSL or TLS and it does not have "https://" at the beginning of the URL, there is an active man-in-the-middle attack on your network. Cease any sensitive activities immediately.
  
• Man-in-the-middle attacks usually require a physical presence on the network. Attacks such as ARP Cache Poisoning may be harder to trace but a lot of the time, an elecronic device needs to be attached to the network, whether it be wireless or wired. Alert the website owners if you ever have this problem and if using a public WiFi connection, disconnect immediately.
  
• When using a public WiFi connection, be extra vigilient. If you find a "Free WiFi HotSpot", ask the owners of the facility (i.e. a coffee shop/hotel/airport) whether the connection you see on your computer is genuine BEFORE you connect. Cofee shops are notorious for these forms of attacks. If possible, disable the automatic connection of all WiFi networks on your computer. The best form of attack in a coffee shop is called "Jasager" or "Yes man", where the attackers WiFi router will mask itself as a network you have previously joined.
  
• When in public, do not leave your laptop unattended. This should be common sense, but even if you can still see your laptop, it only take an attacker seconds to invade your laptop, given physical access. USB Flash Drives called Switchblades, or Hacksaws and most famously coined "USB Rubber Duckys" mask themselves as Keyboards, allowing them greater access to your computers resources. All these pens do is type pre-written commands into the computer, but they do it millions of times faster than a human can.
  
• Educate yourself on Social Engineering techniques. The most flawed part of any network is still the end user. Humans always have been and always will be computer security's biggest weakness; and often the most exploited aspect. Use strong passwords, don't use the same password or group of four or five passwords for everything. If possible use passphrases instead of passwords. A very secure and very easy to remember method is to set your password as "123. This is my Facebook Password, my favourite number is 3.", "123. This is my Google+ password, my favourite colour is #000000" and so on. Set a system so you can have unique, easy to remember pass phrases for each site you use. Changing the three digits at the beginning is enough to create a totally new hash for systems that make you change your password every month or so. Never give your information to anyone, even an official. Social Engineers will pose as law enforcement, internet companies, systems administrators and many other roles to obtain your information.
  
• Be sensible, be careful and use common sense. Treat your online information like you would treat your bank details offline.

[arataon]

A simple way of doing this would be to put something like this on the page that you post to:

<?php
   
   $password = $_POST[password];
   $md5Password = md5(md5($password));

   // Insert into database etc

?>

This double encrypts the password via 2 md5's.

This should be enough for small websites but larger ones I'd use this in conjunction with an SSL certificate.

[ApacheTech]

I would strongly advise against using MD5 to hash your passwords. For the last three or so years, it has been known that MD5 is reaching it's end of life. Recently, this has been officially announced. I would recommend using SHA2-256 (Salted) as a bare minimum level of security when authenticating users. Your salt should be at least16 alpha-numeric characters.

I feel that the web developer community as a whole should push for the W3C (or other iNet regulator) to introduce a new validation badge feature that allows a website to display an industry recognised badge of which method of encryption it uses to store your passwords. In the advent of LinkedIn's catastrophe where they didn't add salt to their hashes and lost over 6.4 million passwords, the web development community has a responsibility to use the recommended minimum security for password storage, especially using salted hashes.

I hate to come over all Battlestar Galactica here, but it has happened before and it will happen again!

Adding salt to your hashes is one of the most important things you can do from a security standpoint. Even a 16 digit salt added to a hash will render the TMT Rainbow Tables statistically useless.

So say we all!

It should be noted that the same report that classified MD5 as EOL, also said that SHA1 will go the same way soon afterwards. In 2005, SHA1 was revealed to have significant weaknesses; including a major entropy glitch which has brought it's EOL date forwards quite considerably. SHA2-256 is now the recognised standard of encryption, however it won't be long (hopefully by 2013) that SHA3 will be officially released.

Again, with any encryption method, always go with the highest bit-length you can; 256 is the standard, but 512 or even 1024 is far better if your database can handle it. Also, always salt your hashes.

I'll write up a full thread on why this is so important if you'd like to know the theory and practice.