Thanks for writing this article. The content is easy to read and is very valuable. I have a comment on the password storage part. While the use of hashing is conceptionally correct, there are different kinds of hashing algorithms and most people would assume the simplest one (e.g. SHAS256). The practical one that is suitable for password hashing is discussed in https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification, which includes PBKDF2, scrypt and Argon2.
I really like the way HTTP vs HTTPS are described, in eay language, please do post negative scenarios or in which cases HTTPS is must or cases where HTTP outperform HTTPS
I have a question: if the session key generated on the client side is stolen by the hacker, wouldn't the hacker be able to decrypt the information just like what they could with public key if there is no session key? why is session key safer than public key?
Thanks for writing this article. Actually have a very simple question for step 2 of "validating password" process. How system fetch the corresponding salt of a password ? There might be cases where multiple salts corresponding to one single password right (multiple user having the same password), how does the system determine the right salt.
Although, if you can, avoid using email addresses as unique IDs. Email addresses tend to change over time, e.g. you business name changes, so the domain is changed, and a variety of other reasons.
You probably still need a uniqueness flag on email addresses, but don't use them as the primary ID.
Yes, even if your system uses 'email' and 'password' to login, you should still have the ability for people to update their email address.
Anyway, that is my aside about using email addresses as unique ids. :)
Thanks for writing this article. The content is easy to read and is very valuable. I have a comment on the password storage part. While the use of hashing is conceptionally correct, there are different kinds of hashing algorithms and most people would assume the simplest one (e.g. SHAS256). The practical one that is suitable for password hashing is discussed in https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification, which includes PBKDF2, scrypt and Argon2.
I really like the way HTTP vs HTTPS are described, in eay language, please do post negative scenarios or in which cases HTTPS is must or cases where HTTP outperform HTTPS
I love your articles, can I ask how do you make the graphics?
Thanks for writing this article about HTTPS,
I just would like to provide a bit of clarification on the key exchange algorithm.
The key exchange algorithm that you described is called RSA and one of the possible options for generating a session key.
A more secure algorithm is called Diffie Hellman.
This algorithm avoid sending the session key over the wire and so it doesn't strictly need the public key contained in the server certificate.
In this case the server certificate is still necessary to verify the authenticity of the server the client is communicating to.
The two different options for RSA and Diffie Hellman are described at https://en.wikipedia.org/wiki/Transport_Layer_Security.
More info about Diffie Hellman at https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange.
Hey Alex, Thank you for the information.
I have a question: if the session key generated on the client side is stolen by the hacker, wouldn't the hacker be able to decrypt the information just like what they could with public key if there is no session key? why is session key safer than public key?
The cipher may change over time, do you recommend migrating the passwords or making the design backward compatible
Note, you can also mention secure coding. How would you go about actually implementing the salt in the backend of a database
Thanks for writing this article. Actually have a very simple question for step 2 of "validating password" process. How system fetch the corresponding salt of a password ? There might be cases where multiple salts corresponding to one single password right (multiple user having the same password), how does the system determine the right salt.
There is an ID column (user_id, email, etc.) which uniquely identifies a row. We can use that to fetch the corresponding salt of a password.
Although, if you can, avoid using email addresses as unique IDs. Email addresses tend to change over time, e.g. you business name changes, so the domain is changed, and a variety of other reasons.
You probably still need a uniqueness flag on email addresses, but don't use them as the primary ID.
Yes, even if your system uses 'email' and 'password' to login, you should still have the ability for people to update their email address.
Anyway, that is my aside about using email addresses as unique ids. :)