4 ms·
I've actually done client side HMAC before to keep from sending passwords in plaintext at least. The site couldn't do SSL at the time. Not perfect, easily MIT
by simcop2387 14y ago
I've actually done client side HMAC before to keep from sending passwords in plaintext at least. The site couldn't do SSL at the time. Not perfect, easily MITM-able but at least not network sniffable.
- MichaelGG 14y agoAre there many scenarios where you can read, but not write, to a network? On WiFi, you can inject if you can read. On a switch, if you are reading via, say, poison ARP, you can also write. Passive taps like mirror ports can't read, but it seems that WiFi/Ethernet/some other physical thing is a more common vector in the first place.
- simcop2387 14y agoLikely not that many. Which is why it only prevents someone from being able to do a replay attack on the login form. (The server chose the secret for the HMAC). It made the better choice for attacking the site to be something more like firesheep to take over the session instead. Though I made that a little more difficult by rotating the session keys after every transaction, so if you take over it would force the other person to be "instantly" logged out and they'd notice and could do something about it (log back in and log out immediately would suffice). Not perfect but also not the worst way to do it (assuming they aren't injecting javascript into the client to do the work anyway, no way to prevent that over only HTTP).