How to send data in secure way between client and server using only Symmetric cryptography

Question

I'd take the following steps to send/received data between client and server. But I'm not sure if all the steps are secure enough and impossible to intercept. Please can you let me know how to patch up the security holes, if any? Please note that:

This is all for Symmetric cryptography not the Public/Private Key method. So 'salt' and 'entropy' are the secrets between client and server.

For some reasons, I cannot/don't use SSL or TLS protocols. So there is no Certificate Authority etc.

Only standard cryptography functions and methods must be used (no inventions).

The data are not sent over a secure (HTTPS) connection.

I cannot use sessions here because they are two different applications.

First time - Sign up (user enters new username and new password)

1. Client side
   1. Create a CSPRNG salt for the user
   1. Save salt on user's machine
   2. Create an entropy in memory (base64 of a temporal value e.g. [hour of the day]+[day of the year])
   3. Post Password(base64 of the plaintext), and salt, and entropy to the server
2. Server side
   1. For the received message from the cliet
   1. Check if entropy matches (e.g. with base64 of [hour of the day]+[day of the year]) .
   2. Compute hash (SHA1) of salt and Password(base64 of the plaintext) - because hashing must always be done on the server.
   3. Save salt and the computed hash to the database

Next time - Log in (user enters his username and his password)

1. Client side
   1. Read salt from user's machine
   2. Compute hash (SHA1) of salt and entered password(base64 of the plaintext)
   3. Post password(base64 of the plaintext), and salt, and the computed hash to the server
2. Server side
   1. Retrieve salt and 'stored hash' from the database
   2. From the received message from the client
   1. Split the message to 3 parts: password(base64 of the paintext); salt; 'received hash'
   2. Compare 'received hash' with 'stored hash'; if they match, the user is genuine not a hacker

Sending TemperProof queryString from user to server

1. Client side
   1. Read salt from user's machine
   2. Create an entropy in memory (base64 of a temporal value e.g. [hour of the day]+[day of the year])
   3. Compute hash (SHA1) of the queryString(base64 of the plaintext), and salt, and entropy
   4. Post querystring(base64 of the plaintext), and salt, and entropy, and the computed hash to the server
2. Server side
   1. Retrieve salt from the database
   2. For the received message from the cliet
   1. Split the message to 4 parts: queryString(base64 of the paintext); salt; entropy; 'received hash'
   2. Check if entropy matches (e.g. with base64 of [hour of the day]+[day of the year]) .
   3. Compute hash (SHA1) of queryString(base64 of the plaintext) and salt and entropy.
   4. Compare the computed hash with the 4th part of the splitted message ('received hash'); if they match, the queryString is genuine

Sending answer back to the user from server

1. Server side
   1. Compute the answer using database queries
   2. Retrieve salt from the database
   3. Create an entropy in memory (base64 of a temporal value e.g. [hour of the day]+[day of the year])
   4. Compute hash (SHA1) of the answer(base64 of the plaintext), and salt, and entropy
   5. Post answer(base64 of the plaintext), and salt, and entropy, and the computed hash to the client
2. Client side
   1. Read salt from user's machine
   2. Create an entropy in memory (base64 of a temporal value e.g. [hour of the day]+[day of the year])
   3. Split the received message to 4 parts: answer(base64 of the paintext); salt; entropy; 'received hash'
   4. Check if entropy matches (e.g. with base64 of [hour of the day]+[day of the year]) .
   5. Compute hash (SHA1) of answer(base64 of the plaintext) and salt and entropy.
   6. Compare the computed hash with the 4th part of the splitted message ('received hash'); if they match, the answer is genuine

The followings areas are the weaknesses, I think. Can you please advise how these can be fixed and also point out the other possible holes?

A) First time - Sign up: The hacker can post rubbish to fill up the database, if he finds entropy in step 1.3

B) Next time - Log in: I cannot think of a way to add an entropy to the hashed password in step 1.2, because then I cannot compare with the one on the server database in step 2.2.2

Thanks

Answer 1

1. The solution is to use HTTPS withTLS 1.2 and pin the certificate, there are certificate solutions that are free.

2. Using a hash (SHA1 in this case) to protect a password has not been good secure practice for some time. For my reference see DRAFT NIST Special Publication 800-63B Digital Authentication Guideline.

3. Passwords must be protected with an iterated HMAC, not a single hash. For more information on passwords see Toward Better Password Requirements by Jim Fenton, see slide 23 in particular. This seems to be at odds with the Pluralsight training, best practices have changes over time.

Answer 2

if you care about security at all, STOP now ...

what you need to do:

1) forget about designing your own crypto protocol ... relying on well known crypto ALSO means that you DO NOT design that kind of thing

2) think in layers ... you have the need to keep things secret while transporting them from A to B ... that means you have a transport layer ... if you want that secured, there is a name for that...
Transport Layer Security -> https://en.wikipedia.org/wiki/Transport_Layer_Security

3) when you make assumptions here like "i have 2 applications so i can not have sessions", please provide WHY you think it is that way... when you think of things like single-sign-on, you can have a lot of applications sharing one authentication method and even session data across a bunch of different plattforms ... maybe it's just you don't know that you actually can have sessions...

4) read up on the terms you use ... you misunderstood entropy ... there is no way of "checking if entropy matches" ... entropy in crypto related cases means randomness in terms of unpredictable input to a function ... if you have something like a date and the time, and even if you hash that, it might look random ... but it is very predictable by someone with a clock... if the communication can be related to the creation time of the value, then your value does not contain large amounts of entropy if it is based on the clock... again, do not design you own stuff here, and go for entropy sources that provide reliable, cryptographically secure randomness (CSPRNG ... not just PRNG)

5) ... you misunderstood/misused salt... that is nothing to be generated on the client machine
that is nothing that needs to be kept on the client machine

7) password hashing again ... DO NOT come up with you own stuff here ... create a sufficently long random salt (at least hash length) for every password. use a slow hash function like PBKDF2 with a high iteration count parameter. the reason is that it becomes slow to test for passwords... your server has to calculate this once for every login attempt ... an attacker has to calculate this for every password testing attempt ... you can afford the test to take like 200ms ... for an attacker that means a lot more hardware will be needed to crack your password storage...

upd:
you want it, you get it ...

proof of concept attack on your schema by man-in-the-middle:

client: alice
server: bob
attacker/eavesdropper: eve

1. alice uses your sign up service and creates an account
   1.1 alice creates a CSPRNG salt and stores that in a secure manner
   1.2 alice gathers an arbitrary amount of entropy and encodes it with base64
   1.3 alice sends Password(base64 of the plaintext), and salt, and entropy to bob
   ------------intercepted-------------
2. eve intercepts the communication between alice and bob and gains knowledge of...
   2.1 ...the base 64 encoded password -> base64 decode -> the plaintext password
   2.2 ...the salt
   2.3 ...the entropy value
   2.4 alice forwards the intercepted communication without changes to bob

--- protocol broken ---
now, bob is by no means able to distinguish between alice and eve in all further communication

upd2:

a look on your transfered (cleartext) messages:
Login:
Post password(base64 of the plaintext), and salt, and the computed hash to the server Sending queryString from user to server:
Post querystring(base64 of the plaintext), and salt, and entropy, and the computed hash to the server answer:
Post answer(base64 of the plaintext), and salt, and entropy, and the computed hash to the client

now for any of those messages, let's look at what information someone with malicious intent would learn from those:

all the information that is cleartext, which means, all of it ... for the login, we gain the clear text password, means from now on an attacker can identify as a valid user

for the querystring and answer thing you want to provide a way to see if the request/answer is not tempered with.

so if an attacker now intercepts your communication how can he change the querystring without being noticed? the attacker splits your message, and changes whatever he/she wants then he/she computates the forged_hash as sha1(salt_from_the_original_message,tampered_querystring) and sends base64(tampered_querystring),salt_from_the_original_message,entropy_from_original_message,forged_hash to the server ...

for the answer it's the same deal:

the attacker intercepts the original answer, changes whatever in the answer and recomputes the hash based on known information (the changes, and the original salt)