2013 Sep 27 08:39 PM MDT | Security² Web¹³ [2013]³

**HTTP does not encrypt** any traffic. Any of the **internet routers** can see and log your traffic, and your passwords might be compromised if the server does nothing to alleviate this.

On my arcade, my login form requires JavaScript to be more secure, but it is not perfectly secure.

The **first transmission of the password might be intercepted, which is a vulnerability** of this method.

However, this is the only time when the password is at risk of interception. Also, the passwords cannot be protected at rest, since the password cannot be salted by the server. Comparing against salted hashes requires the original password to be transmitted. The hashing mere acts as a compression function, so it is **as if the server stored its passwords in plaintext**.

During authentication, instead of repeating the first, only **a hash** of [the password (for compression to make it easier to store at the server), fixed data, and a bunch of random data and timestamps] is sent, **from which the original password is not easily derived**. This prevents **replay attacks** as the timestamp must be recent (or exceed the last timestamp used, at risk of locking out), but users need to wait 1 second between logins, which is not an issue. Also, the request can also be denied if the **random data matches the previous** data, at the risk of a collision. The random data helps to add more entropy and to **make reversing of the hash** more difficult. Also, when the hash can be fully reversed, the **hash algorithm can be changed at any time to increase security, but the passwords must also be changed**.

This hash can be rebuilt at and compared against by the server, since the timestamps and random parts are transmitted in the clear, but the password is not. Basically, **this is a custom HMAC** that is used to sign a timestamp and a random number that must not be the one previously used.