Digest will not protect against a MitM, so in that situation you are already doomed, but only locally doomed: the attacker can see your data, and alter your requests, but he does not learn your password so he will not be able to come back later by himself. Note that one possible advantage of Digest over Basic is that you do not reveal the password even to the server itself, in case that server is hostile - by which I mean that you are talking to a fake server, controlled by the attacker. No amount of Digest will save you in that case. We know, however, that not using SSL is a big problem anyway, because attackers have advanced a bit since last century: they no longer content themselves with passive eavesdropping, they actually hijack connections and implement man-in-the-middle attacks. This makes things clear: Digest was designed to try to cope with the glaring issue of sending passwords in the clear, as Basic does when not used with SSL. This is the only reference to SSL in the whole document. Password are passed over the network as cleartext. Method of user authentication (unless used in conjunction with someĮxternal secure system such as SSL 5), as the user name and This scheme is not considered to be a secure "HTTP/1.0", includes the specification for a Basic AccessĪuthentication scheme. The RFC begins with this paragraph, which gives the context: The Digest protocol specification dates from 1999, which was a time when SSL was still viewed as a tool too expensive to be employed generically.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |