New HTTPS Bicycle Attack Reveals Details About Passwords From Encrypted Traffic (softpedia.com) 78
campuscodi writes: Dutch security researcher Guido Vranken has published a paper [PDF] in which he details a new attack on TLS/SSL-encrypted traffic, one that can potentially allow attackers to extract some information from HTTPS data streams. Attackers could extract the length of a password from TLS packets, and then use this information to simplify brute-force attacks. The new HTTPS Bicycle Attack can also be used retroactively on HTTPS traffic logged several years ago. Hello NSA!
We need to ban them immediately (Score:1)
Everyone knows only terrorists use bicycles. Good citizens should stick to unicycles.
Re: (Score:2)
No, good citizens will buy a Chevrolet Volt.
Re: (Score:1)
Re: (Score:2)
Best regards,
The Kingdom of Saudi Arabia
Re: We need to ban them immediately (Score:4, Funny)
> Good citizens should stick to unicycles.
You have nothing to lose but your chains.
How useful really is password length? (Score:5, Insightful)
Seems to me that if you wanted to brute force something, you'd start with the minimum size allowed and go up from there. If there's 50 different characters allowed for any letter of a password, then testing all possible 7-length passwords takes 1/50th the time as testing all possible 8-length passwords, and so on. Negligible.
I guess it could be useful to know whether or not a given password IS brute forceable, though, and give you a rough ETA. An attacker could say "huh, this guy only has a 6 letter password, we can grab that in a minute", or "this guy has a length 20 password, we have no chance".
Re: (Score:2)
Seems to me that if you wanted to brute force something, you'd start with the minimum size allowed and go up from there.
Exactly.
I think this attack is probably going to be minimally useful at best, and even then only for very short, stupid passwords.
Re: (Score:3)
"I think this attack is probably going to be minimally useful at best, and even then only for very short, stupid passwords."
Re: (Score:2)
OK, everyone - time to update your passwords - "54321" is 4.400243 times better than "12345"
Re: (Score:2)
I would have hoped that security products that send encrypted passwords would insert random junk to randomize the length of the message containing the password. Since the password is in a predictable place in the data stream, it would make sense to garble it as much as possible, no?
Re: (Score:3)
Re: (Score:2)
Mostly, it's a useful lesson to future protocol designs - next iteration should protect against this by sending some standard length block (SHA3?) of the password so that all information about it is obscured.
Re: (Score:2, Insightful)
If you're targeting an individual user, you can look at their password lengths across multiple sites (to attack them where they're weakest, for example)
If you're targeting one *site*, you can look at the password lengths across all the users and attack the users (or subset of users, like admins or influential users) with the shortest passwords.
Re: (Score:3)
Re: (Score:2)
Why not just phish users using a fixed value for x?
Put some spelling and grammar errors in the email too, that usually weeds out people smart enough not to fall for it. They just end up wasting your time.
Re: (Score:2)
You could also use the information to try to phish the users. "We noticed that your password is only x characters long, in order to increase security we are requiring passwords of at least x+y characters long, please click this link to reset your password"
I'm pretty sure any user this would work on would be equally susceptible to the same email with a universal value of 6, 7, or 8 for everyone.
Re: How useful really is password length? (Score:1)
Eh? If you know the password is 13 chars why would you bother guessing shorter passwords?
Re: (Score:3)
Re: (Score:2)
Re: (Score:1)
Every bit of information is helpful to an attacker. Ill bet the person trying to gain access to your accounts has a lot more information on you than you think. All in hopes to get what they want.
Re: (Score:2)
Indeed. Length information can only tell you when to stop, because you have missed the password (e.g. because you did not use the full char-set on some assumption of language used) and how much effort is expected. The effort for shorter passwords is negligible. Takes some actual Math skills for seeing that (not very advanced ones though), and these seem to be in very short supply these days. Civilization is really devolving, with people knowing and understanding less and less.
Re: (Score:2)
That is not brute-forcing. Incidentally, how do you arrive at 256 values per character? If it is characters you find on a keyboard, they will be far less. If it is Unicode, they may be far, far more. They will never be 256 in practice, unless it is a binary key, not a password. I will not even comment on you amateur-level analysis of the search space. Well, what can one expect from the typical big-ego-small-skill AC.
Only valid for stream ciphers. (Score:4, Insightful)
Not sure how he would get the results with block ciphers but the paper only describes stream ciphers. That's the reason we don't use stream ciphers for HTTPS but rather block ciphers. Stream ciphers should simply never be used where keys repeat.
Re: (Score:3)
Re: (Score:3)
But the predictable stream length attack has been known about since the introduction of stream ciphers. That's why you don't use stream ciphers (or shouldn't at least) to secure predictable content like chunks of websites. You use block ciphers that ALWAYS has the same block size regardless of it's contents.
AES-GCM seems to be fast-tracked by US governmental agencies with at least one someone trying to (inadvertently?) sneak in an exploit in the OpenSSL implementation. Don't trust new ciphers too quickly, i
Search sites (Score:2)
Re: (Score:1)
Most ciphers used now (other than Salsa20) are block ciphers, not stream ciphers. Therefore they work in blocks, and are padded to fit said block size. This means that there is less information available to mount an attack like this to get exact size, but you would still be able to tell it is between two values. The only real solution is for HTML forms to have a standard padding scheme so that way logins are all the same size.
Serious vulnerabilities (Score:2)
It's a good thing Guido discovered the need for padding when riding bicycles because you could fall and hurt your head.
Not the end of the world (Score:2)
The attacker needs to know the exact length of all the other data. That means they need all the cookie data being sent, etc.
Re: (Score:2)
Some of this is highly predictable. A given application could use only a single cookie, and that cookie could always be of exactly the same length. There might be some variation in the headers such as Content-Length, but for password submissions, this is unlikely to vary by more than a character or two. Predictability could be extremely high.
Some protocols are even more predictable.
Re: (Score:2)
So easy way to thwart it: Google Analytics, with its __utma and __utmb etc cookies that end up with every request to your domain.
There's also the User-Agent header that varies depending on the user.
There may be an If-Modified-Since header, an ETag header (although probably not on a POST request)
Accept, Accept-Encoding, Accept-Language, cache-control, origin, Referer, Connection. Those are all headers my browser is sending to slashdot.
It's even difficult figuring out what the URL in the request is, since tha
Re: (Score:2)
That's for a random MITM attack. If the attacker controlled the non-https page that sent you to the https page he wanted information from almost all of that is predictable.
Re: (Score:2)
Given that almost all HTTPS sites are mapped 1:1 domain:IP address, it's not that hard to figure out what site it's connecting to. That brings some level of predictability, especially if one already has access to the site via another account, or it uses an established framework.
Watching unencrypted traffic from your browser is going to hand over some of that information. It's not necessarily that one can simply look at a payload length and quickly determine the password length, but that by using various k
no need for that. ~ subtract the last request (Score:2)
Suppose an attacker is targeting a log in page. To load the page, your browser makes several http requests - the html page itself, a css file, a JavaScript file or two, some images that are on the page, etc. The cookie, user-agent etc are the same for all of these requests. Therefore the attacker already knows all they need to about the length of all your headers wven before you submit the login form.
By trying it themselves ahead of time, the attacker knows that a login with an 8-character password will
Variable length header (Score:2)
In the case of HTTP, I wonder if causing an ever changing header to be sent could help. For instance change a cookie on each exchange, with random length.
In the case of POP, IMAP or SMTP, we are screwed, though.
https bicycle attack (Score:5, Funny)
I think this is taking the Internet of Things too far.
Re: (Score:2)
We should have stopped after the unicycle attack. That was taking the IoT one far.
Should have been more than enough warning.
Hash those pedals (Score:2)
Re: (Score:1)
Not particularly - then the hash becomes the new password. You'd need a client side hash with a nonce, and even then, the server needs a way to be able to validate the client-generated hash without storing the password in plaintext.
Re: (Score:2)
Not a random length. You want a fixed total length. Say your longest possible password is 64 characters. You want to pad out every password to 96 characters, so if the users password is only 6 characters long an additional 90 random characters are padded. That way no statistical attacks can be performed.
Major, sort of (Score:2)
Knowing the length of a password cuts the keyspace in half -- assuming that one starts a brute-force search from shortest to longest -- because you can skip 2^(n-1) keys. That's huge, but if your passphrase is long enough, then that's still just the difference between the several times the heat-death of the universe and a couple of times the heat-death of the universe.
But even if that's an appreciable difference, this is still only useful for targeted attacks, and in those cases, there are better vulnerabi
Why bicycle (Score:1)
From TFA:
The name TLS Bicycle Attack was chosen because of the conceptual similarity between how encryption
hides content and gift wrapping hides physical objects. My attack relies heavily on the property of
stream-based ciphers in TLS that the size of TLS application data payloads is directly known to the
attacker and this inadvertently reveals information about the plaintext size; similar to how a draped or
gift-wrapped bicycle is still identifiable as a bicycle, because cloaking it like that retains the unde
Re: (Score:2)
...similar to how a draped or gift-wrapped bicycle is still identifiable as a bicycle, because cloaking it like that retains the underlying shape.
So then why wasn't it called the vacuum cleaner attack?
http://images-cdn.9gag.com/pho... [9gag.com]
This is why we don't need back doors (Score:2)
With politicians want to push for back doors, this illustrates why we don't need them. Normal encryption has its weaknesses, flaws and limitations, which a well resourced 'intelligence' agency can take advantage of. Add the back doors and you have just expanded on the weaknesses, flaws and limitations, that would drive people to another form of encryption.
Perfect Forward Secrecy? (Score:2)
Re: (Score:2)
I think you're reading too much into the name. PFS doesn't guarantee that the message will remain secret forever, or even that the encryption can't be broken by brute force at some point in the future. It just means that the encryption key is ephemeral: it's generated using e.g. Diffie-Hellman, which allows two or more nodes to arrive at a secure shared secret despite the presence of eavesdroppers, and it's discarded by both sides after the communication is complete.
The alternative is encrypting the traffic