![]() If someone intercepts the transmission, therefore, they don't need your actual password : it's enough to replay the message with the hash they captured. This is an interesting idea, but if I've understood it I think there are two flaws - both based around the fact that essentially now your password is the plaintext hash as far as the server is concerned. Is this worth taking further? Of course, if you can't trust a company to securely store your password properly, it's unlikely they'd implement this properly. That's probably a bit overkill - and you'd need to make sure you used the same configuration every time someone logs on - but it means no one other than you ever sees the password. The server should not store the hash directly - but rather encrypt it first. Now, obviously SHA-1 isn't secure, but it means that I don't send hunter2 to the server, I send f3bbbd66a63d4bf1747940578ec3d0103530e21d. Let's now add "encrypt the password with this algorithm before sending it": Suppose we have an HTML password field which insists on a minimum of 6 characters: ![]() So, how do we send the password without sending the password? Once you know my email address and found out my password - you can try it against of range of services. Or, incompetence could lead to a range of easily cracked passwords leaking out. ![]() Or, a corrupt sysadmin could steal the password. It then hashes it and compares it to the hashed value it has stored in its database.Ī malicious party could intercept the password either by sitting between me and the server - or by compromising the server itself. It is (one hopes) encrypted in transmission, but once it arrives at the server there is a brief window where the server holds my password in plaintext. When I want to log in to a system on the web, I have to send that system my password. There are rarely new ideas in cryptography - and I doubt this idea is particularly innovative - but I thought it would be worth discussing.
0 Comments
Leave a Reply. |