Security is becoming an increasingly important topic as business applications become more frequently accessible through the web and are, as a result, more vulnerable to threats. As 4D is closely paying attention to security matters, in 4D v16 R5 we are providing you with a couple of security improvements, and one of them relates to the web users’ password protection through password hashing.
By the way, if you want to know more about how 4D is helping you to protect your data and with the security in general, I recommend you to take a look at this blog post.
Why passwords should be hashed?
Let’s take a concrete example – you have a business application, with users who can sign in by entering their name and password in a dialog. Once signed in, users gain “extra rights” such as reading and writing in other tables or fields (for instance, Human Resources department can access employee salary table but not employees themselves).
The server must then store “something” which can be used to verify user passwords. The most basic “something” consists of the passwords themselves. Any unsecured password saved in your database could be stolen and used to compromise your application and your data. If you hash your user’s passwords before saving it in your database, the original password cannot be found or decrypted. But, you can still compare the hash to the original password to check the validity.
Hash or Encrypt?
The first thing to note is that there are many people who talk about encrypted passwords but really mean hashed passwords.
Encryption uses an algorithm to encode data which can be decrypted by a key to get the original data back. In hashing, once the data is encoded, there is no way of retrieve the original data. Thus, passwords should be hashed and not encrypted.
A consequence of password hashing is that since you do not store the passwords themselves (but only a piece of data which is sufficient to verify a password without being able to recover it), you cannot send back their passwords to users who have forgotten them. Instead, you must select a new random password for them, or let them choose a new password.
What algorithm for hashing?
The algorithms like MD5 or SHA are very fast then they are vulnerable to brute force attack, as a consequence they should not be used to hash passwords. The bcrypt algorithm is slow by design, it aims to be slow, so it is perfect for password hashing. For more information, I advise you to read the “How to safely store a password” article from Coda Hale.
Commands to hash passwords
Two new commands have been created to generate and verify a hashed password. These commands are based on the bcrypt algorithm.
- A new user creates his account with the password: “myPassword“. I generate the hash password with the new Generate password hash command, then I saved the hash password in database.
$varHash:=Generate password hash("myPassword")
[User]Login:=$varLogin
[User]HashPassword:=$varHash
SAVE RECORD([User])
- When my user tries to connect, he enters his password. Then I check the validity between the password entered by the user and the hash password stored in database with the new Verify password hash command.
C_TEXT($varLogin;$varPassword) // information entered by user
QUERY([User];[User]Login;=;$varLogin)
If (Records in selection([User])=1)
// Compare the password to the hash password
If (Verify password hash($varPassword;[User]HashPassword))
SendToUser("You are connected. Welcome "+$varLogin+".")
Else
SendToUser("You have entered a wrong password.")
End if
Else
SendToUser("You have entered a wrong login.")
End if