I'm using HTTPS Everywhere on my browser to chose SSL versions of websites when available, but many sites don't offer a secure version. Is SSL the only viable option to thwart password/clear text sniffing?


If you don't want to send your data in plain text, you have to use encryption, but it doesn't always have to be SSL. For example, a site might choose to do their own encryption at the application level instead of just using SSL (though I can't imagine why anyone would ever do that >_<).

However, if a site doesn't offer this encryption, there is nothing you can do to avoid sending your data in plaintext. After all, the site is expecting it in only plain-text. You can't change that without changing what the site expects.

  • "though I can't imagine why anyone would ever do that" - extreme naïvety, perhaps? :) – Polynomial May 22 '12 at 13:04

You need to use encryption, even if it doesn't matter what kind.

There is one other (pretty useless probably) thing that you could do that comes to my mind, since you are asking if there are other options to defend yourself against password sniffing: web apps could be modified to work with password hashes instead than with plain-text passwords, as @Oleksi said. This way, at least, if you sniffed a password, you would have a bit of work to do before you can get to the plain-text password.

But of course, using encryption is better.

  • 1
    It does matter what kind. c[n] = m[n] xor k[n mod len(k)] where len(k) < len(m) is encryption, but it's practically useless. – Polynomial May 22 '12 at 13:06
  • @Polynomial sure, I should have said "it doesn't matter at which level in the ISO/OSI stack", as Oleksi pointed out. – user1301428 May 22 '12 at 14:02

It is theoretically possible to get password-authenticated connections without encryption. A putative protocol for that would begin with a password-authenticated key exchange (such as SRP), resulting in a shared secret, known to both client and server, but nobody else; and client and server would be mutually authenticated with regards to the knowledge of the password. The shared secret would then be used as key in a MAC algorithm, for maintaining the integrity of the subsequently exchanged data packets. And there you go: password authentication, yet no encryption, and you are still protected against online dictionary attacks: eavesdropper learn nothing about the password, not even a hashed-or-equivalent value which would allow them to test potential passwords afterwards; and this property is maintained even when faced with active attackers, even attackers who impersonate the server or the client. Such is the magic of PAKE protocols.

Of course, no encryption means that the subsequently exchanged data can be inspected by indiscreet spies; integrity is maintained, not confidentiality. This is often an issue in its own right.

(Not all problems are solved with such a protocol, though. Registration would be hard to do without leaking to outsiders at least a hashed version of the password.)

In practice, a cryptographic protocol is "viable" only insofar as it is implemented properly by all involved parties. The theoretical possibility of a cryptographic protocol which does password authentication without encryption does not change the fact that, right now, Web browsers do not implement that. Web browsers implement SSL (HTTPS). So, use SSL. It is the only reasonably secure way of handling password authentication when the client is a Web browser which exists and is widely deployed as of early 2013.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.