a login system with data encryption has been developed, but still not finished.
There are some safety risks pending, mainly regarding public and private keys exchange, to be written.
Moreover, the login sequence is complicated and not debugged, but I’m planning to simplify it, introducing key exchange. Finally, other details must be polished, including post data sanitizing, error handling and page appearance.
Instruments
It is based on php, jQuery and a sqlite database.
The source is on github at this link: https://github.com/Fred68/Cryconn.
A test page is here http://fred68.altervista.org/test/ , go to main link.
Test users are [username, password]: [a, a], [pippo, antani] and [pluto, blinda].
I wish to thank Travis Tidwell, Tom Wu and CryptoJS team for their amazing work, and Bruce Schneier for his wonderful cryptography essay.
Description
The system uses some javascript libraries for encryption and other functions:
jquery, ver. 3.1.0: jQuery library, from: https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js
crypto-js, ver. 3.1.2: hashing and Aes encryption functions, from https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.2/
jsencrypt, ver. 2.3.1: RSA encryption, from: https://cdnjs.cloudflare.com/ajax/libs/jsencrypt/2.3.1/jsencrypt.min.js
In php the corresponding and compatible functions are made with openssl library.
Criptogrphically secure random numbers are generated with openssl_random_pseudo_bytes function.
In js a secure function does not exist, so js key pair is not secure (the whole js is insecure itself).
Data are kept, through session, in session variables in php and in sessionStorage in js.
The login system includes:
– A login with user and password
– A php sqlite database with a user names and hashed password table, and a logged user table
– A multiple login check
– A timeout check and refresh with a js timer
– A double key user data exchange, including the aes random key, valid for one session only
– An AES encrypted data and command exchange
– A preliminary public or private key dispatch (aes encrypted), to be downloaded as a text file in client pc (only test)
– A preliminary client pc local file reading, to retrieve public or private key (only test)
Login sequence
1. js: On click login, the client sends CMD_LOGIN + user + password hash 2. php: The server checks user and pwd, sets session variables and adds it to connected users table. Then answers with ID_START and sid (session id) 3. js: The client stores sid into session. Then executes ID_START: starts a timer. Then executes CMD_CONNECT: js generates RSA keys and stores puk (public key) into session. Finally the client sends CMD_CONNECT + puk 4. php: The server generates AES key, binds it to sid, encrypt all with received puk and converts into base64. Then answers with CMD_CONNECT + aes e sid, encrypted. 5. js: The client decrypts the data, stores AES key and checks the sid. The client answers with CMD_AESPK, a request for aes check 6. php: The server generates (secure) RSA keys Then sends CMD_AESPK + puk 7. js: The client stores the puk. Then executes CMD_AES: encrypts the AES key with the puk key. Send it as CMD_AES command. 8. php: The server decrypts AES key using the prk (private key). Then compares it with the storerd aes key. Finally ansers with CMD_AES and the hash of the aes key (no encryption needed) 9. js: The client checks the hashed aes key with the stored key. Command sequence (after login): C1. js: The client sends CMD_COMMAND + encrypted command with AES key C2. php: The server decrypts the and executes it. Then composes the answes as a string command=text. Finally the server encrypts it with AES key and sends with CMD_COMMAND command. C3. js: The client receives CMD_COMMAND, decrypts the command and executes it. Command execution (client js): default Shows the message CMD_PRK The client extracts the text containing the private key. Then shows the download link, creates a blob with the text and associates it to the link target. Command execution (server php): CMD_PRK The server generates a pair of RSA keys and sends the private one (aes encrypted). Then it should store the public key and check the client received the private key [to be done] Buttons Prk Sends a CMD_COMMAND with CMD_PRK cokmmand.
Unsafe procedure points
1. The hash can be reproduced, locking or altering login and logout. No authentication provided, nor timestamp.
The password or the hash could be encrypted with private key, but and attacker could resend it.
The password hash could be encrypted with a timestamp, the data will change every time, but could be reused, if no timestamp check is done by the server.
Probably the issue could be solved with a preliminary key pairs exchange.
2. The server sends the siession id in clear.
An encryption probably is useless, considering the session id is sent in clear when connection is established.
3. A MITM (man in tha middle) could replace the public key with one generated by himself, the intercept server response and replace the answer with his own.
A safe preliminary key exchange is mandatory.
6. The server answers with constant data, unauthorized decryption is easied.
Other vulnerabilities
1. sessionStorage
2. Random number generation
3. session id
4. js code (better encrypted)
5. online content data
6. Server data security (sqlite and code hidden with htaccess only).
7. No https. A Let’s Encrypt solution is probably easier and more affordable.
The work is still in progress.
Regards,
Fred