5 ms·

In the article Ash writes: > Basic HTTPS auth makes it easy to crack the protocol's encryption and get the username and password. Does anyone know what he is

by mcherm 14y ago

In the article Ash writes: > Basic HTTPS auth makes it easy to crack the protocol's encryption and get the username and password. Does anyone know what he is referring to? He also says: > However, getting [a value] isn't difficult; it's easily accessible by a malicious user using an HTTPS proxy. That, I am fairly certain, is not a serious concern because HTTPS uses a certificate chain to prevent the use of proxys. Sure, someone capable of generating bogus certificates (the NSA, for instance, and probably several other powerful governments) can insert a proxy without your knowing, but if they can do that then they can ALSO undermine the entire world financial infrastructure. Anyone capable of doing that is probably NOT going after YOUR app.

AshFurrow 14y ago
Repeated username/combo requests over HTTPS produce patterns over multiple requests that can make cracking the encryption easier. Additionally, there's the issue of having to store usernames and passwords somewhere in the app (hopefully not plaintext, and hopefully somewhere inaccessible). As for proxies, I'm talking about someone with physical access to a device and network, which I believe would work for extracting unencrypted HTTP headers from HTTPS requests (that's why an OAuth signature is itself encrypted by the consumer secret and user authentication token). However, I'm not a network security expert, so maybe I am mistaken.
- mcherm 14y ago
  > Repeated username/combo requests over HTTPS produce patterns over multiple requests that can make cracking the encryption easier. Interesting! Do you have any references where I can read more? > As for proxies, I'm talking about someone with physical access to a device and network HTTPS really does protect against someone with physical access to the network, by encrypting the data streem and preventing man-in-the-middle attacks (except by attackers who can subborn a trusted root authority). It does NOT protect against someone with full access to the "device" where the client app is running -- someone with such access can, more-or-less by definition, view all values that the program sends (including credentials).

by mcherm 14y ago

AshFurrow 14y ago

Repeated username/combo requests over HTTPS produce patterns over multiple requests that can make cracking the encryption easier. Additionally, there's the issue of having to store usernames and passwords somewhere in the app (hopefully not plaintext, and hopefully somewhere inaccessible). As for proxies, I'm talking about someone with physical access to a device and network, which I believe would work for extracting unencrypted HTTP headers from HTTPS requests (that's why an OAuth signature is itself encrypted by the consumer secret and user authentication token). However, I'm not a network security expert, so maybe I am mistaken.

mcherm 14y ago
> Repeated username/combo requests over HTTPS produce patterns over multiple requests that can make cracking the encryption easier. Interesting! Do you have any references where I can read more? > As for proxies, I'm talking about someone with physical access to a device and network HTTPS really does protect against someone with physical access to the network, by encrypting the data streem and preventing man-in-the-middle attacks (except by attackers who can subborn a trusted root authority). It does NOT protect against someone with full access to the "device" where the client app is running -- someone with such access can, more-or-less by definition, view all values that the program sends (including credentials).