In the previous section we outlined an application where the two pertinent functionalities are user registration, and login. Pretend that the user registration is done securely, and the user has altered the password to a secret one.
We shall first demonstrate that required functionalities are in place. We start the server, and access it by linking to http://localhost:3000 in the browser. Then we shall
We have verified that something actually works. Let us verify that the database actually holds a hashed password, and thus meets the cornerstone of all user security that passwords are never stored as clear text.
select * from user;
+-------+--------------+-------+----------------------------------------------------------------------------------------------------------------------------------+
| name | email | phone | password |
+-------+--------------+-------+----------------------------------------------------------------------------------------------------------------------------------+
| anat | anat@x15.dk | 5432 | ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff |
| jane | jane@doe.com | 1236 | x |
| john | john@doe.com | 1235 | x |
| Niels | nmla@iba.dk | 3306 | d404559f602eab6fd602ac7680dacbfaadd13630335e951f097af3900e9de176b6db28512f2e000b9d04fba5133e8b1c6e8df59db3a8ab9d60be4b97cc9e81db |
| tulle | tulle@x15.dk | 1234 | ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff |
+-------+--------------+-------+----------------------------------------------------------------------------------------------------------------------------------+The hashes, done with SHA512, are 512 bits long, 64 bytes, and stored as hexidecimal digits amounting to 128 characters. This is pretty normal.