How long is your password? HTTPS Bicycle attack reveals that and more A new attack on supposedly secure communication streams raises questions over the resilience of passwords, security researchers warn. The HTTPS Bicycle attack can result in the length of personal and secret data, such as passwords and GPS co-ordinates, being exposed from a packet capture of a user's HTTPS traffic. The attack …
No, the reverse: pad out every password to a fixed length, say 1000 characters.
Suppose the random data has a minimum length of Rmin and the password is of length P. If you observe lots of packets, you will discover the minimum payload length is P + Rmin. Examining the code should reveal Rmin so you still get P. All you've done is fractionally delay the attack.
1000 characters? That's pretty wasteful, unless you know some people with 999 character passwords that are worried about brute force attacks if someone finds out they aren't 1000. I'd hate to have that if I was browsing a site on mobile data that encoded my password into every HTTPS transaction.
Padding to 16 or 20 characters should be enough for anyone - those with longer passwords are not going to get brute forced in our lifetime unless they use the 'correct horse battery staple' password.
My point was that if someone uses something longer than 20, yeah maybe you can find out their password is 28 characters, but is that going to help you brute force it? No.
And one in several thousand people are using a password longer than 50 characters? Who the hell wants to type that every time they login?
Knowing that the length is 21 characters does help. I'm not sure why you are dismissing "correct horse battery staple". Obviously one wouldn't use that exact phrase, but the general idea of forming a password from dictionary words is sound. Not only is it easier to remember, it's easier to type than some random characters. The dictionary XKCD used had 2,048 words, hence 11 bits per word, hence 44 bits for 4 words. That is short enough to brute force, especially if you know the exact length (23 characters in this case).
Agreed, 20 characters of padding even monkey123 is not going to help cracker past the 3 billion years it would take him to figure out 1) where monkey123 fits, and 2) what the padding actually is - and by most forced - or smart - rules, isnt going to be letters and/or numbers. Even IF the number of characters can be somehow derived, and they probably cannot.
No...
Not exactly.
The only way you would know the length of the password if you know the length of the buffer and the max length of the pad and the minimum number of characters required for the password.
So length of P = length(buffer) - pad_max iff length(P) > password_min_length.
e.g.
Length of buffer= 510
pad_max = 500
password_min_length = 8
So we know that the length of the password to be 10 bytes. (characters)
But if the length is less than 500 you wouldn't know its length.
Surely this is a total statement of the obvious.
Basically saying if you know all the data used for login except password (i.e. know username) for a site login (and what browser they are using so can work out size of all the total cruft in the request) then on the simple login request you can work out how much data is taken up by rest of the https request & so deduce password length.
Hasn't everyone been aware of this possibility with a non padded password field since https on the web started?
quote from TLS v1.0 definition, published in 1999:
Any protocol designed for use over TLS must be carefully
designed to deal with all possible attacks against it.
Note that because the type and length of a record are not
protected by encryption, care should be take to minimize
the value of traffic analysis of these values.
I think we can expect analysis of ROT13 from them, and their "shocking" conclusion that it is not secure.
Side-channel attacks, including attacks on the message length, are indeed well-known.
There is still useful information in the paper, as you'd know if you read it. In particular, there are useful examples of practical analysis of the information.
Now, of course we know that all Reg readers are genius experts in every IT-related field, so nothing here will be new to any of us. But some mortals might learn something from it, so perhaps you could be a bit more generous and not dismiss it out of hand?
Fpr the shoulder surferus out there, I want to see more implementations of:
Keypads (or virtual screen pads) that randomly change character positions after each press (milspec, I know),
Allow a password to be entered first (MANY systems do not allow or account for this), THEN the username - most shoulder surfers already might know your username, so they wont stare at the first few characters typed to somewhat avoid being detected, because they are assuming you are entering the username first as is customary/habit, when they finally look, they now see you already entered a password, they are kind of screwed.
Rhythmic entry - where a certain beat pattern is typed, or a space of time required between one or two sections of a UN or PA entered. (again, I know, already military grade) - so for monkey123 as a PW, you might be required to enter it as
monk (pause) ey1 (pause) 23
It looks natural enough to the casual shoulder surfer, but is indeed required for correct entry.
I also like the idea of Duress Passwords - words that would trigger a modicum of data destruction or re-encryption to another, waiting in the wings, password. So the next time you enter your password, it must be the next one waiting in that list.
So I might have monkey123, but have giraffe456, gazelle789 waiting just in case I enter the destruct code :animal000 (or some such pre-planned code)
So, if under duress, I would enter animal000, my data would give the apperance of being destroyed or a message could pop up saying, "server is off line please try again later", hopefully fooling my aggressor.
Then later, in relative safety with my agressor gone, I would from then on need to use the next password in my list, which would - after destruction - no longer be monkey123, it would now be giraffe456 - my data in reality still intact just re-encrypted for use with the new PW and its salt/hash.
All coding for these approaches would be trivial and barely a blip of resources used.
This post has been deleted by its author
Infact this issue came up a while ago on one of the OpenBSD mailing lists.
"In fact". Two words.
And the fact that message-length side-channel analysis has been discussed in some forums does not disprove the original claim, which was that "it is usually assumed that HTTP traffic encapsulated in TLS doesn't reveal the exact sizes". Indeed, it's not even evidence against that claim.
I know, reading is hard.
Blast!. Now I must protect my blog by adding more headers like pointless reloads and some more of those FrontPage ones that litter every web page.
Can't have vile spoofers pretending to be me and fooling my reader (the other one recently decided to unsubscribe over some piffling blink tag issues).
That's my solution; really, really long passwords and this attack doesn't change anything around still having to step through it, character by character which he does point out in the paper (and the blog AAMOF). PasswordSafe, or other solution, is decent for generating nonsense password, again really, really long.
As for El Reg? Use a throw away password since it can be intercepted on the fly, no decrypt required. Fortunately, there are fewer and fewer sites that just don't give a damn.
This post has been deleted by its author
So this attack requires "The TLS traffic must use a stream-based cipher" (because it would already be padded using a block cipher), and "the website we are sending the login attempts to has no threshold or prevention on failed login attempts."
You would hope that not many websites fulfill both of those.
Which versions of TLS support stream ciphers - it wasn't obvious from a quick search. Can you configure a browser to not support it?
Which versions of TLS support stream ciphers
All versions of TLS have RC4 suites, though RFC 7465 retroactively prohibits them. RFC 7465 is standards-track but not yet a standard, so technically all versions of TLS still have RC4 suites. Many people have disabled them.
TLSv1.2 can use the GCM combining mode to create a stream cipher from a block cipher (namely from AES; I don't think there are any Camellia GCM suites, or for that matter Camellia TLS 1.2 suites).
The GCM suites aren't supposed to be used with earlier TLS versions, per RFC 5288.
So the Bicycle attack applies primarily to sites that are still using RC4 - there are quite a few, because many sites switched to RC4 after BEAST was published in 2011 - and to TLSv1.2 sites using AES-GCM, which is often promoted as best practice.
https://en.wikipedia.org/wiki/Digest_access_authentication
Essentially it means that you'll never send your password over the connection, but only random numbers and hashes. This is a feature in HTTP which is there for probably over a decade.
This is a feature in HTTP which is there for probably over a decade.
Almost two, in fact. RFC 2069, published January 1997.
The problems are, first, that few people support digest authentication; and second, that if you're going to go to the trouble, you might as well use a ZKP protocol like SRP or PAK-RY, which are in principle more secure because the server never sees anything other than a verifier.
And, of course, HTTP digest authentication as such uses the browser's credentials dialog, and no self-respecting Web 2.0 site will sacrifice the opportunity to use its own shiny username and password dialog. Eye candy is far more important than security and convenience.
Sites could in principle implement the mechanism directly, but I don't believe that I'd trust most of them to do so.
I appreciate hearing about HTTPS leaking password length and other data. The call for 2FA is excessively annoying. Every day I'm forced to use two separate devices for 2FA that I'm forced to use and didn't want. If I enabled 2FA on everything I'd have to have 4 devices with me at all times including being forced to carry a Windows laptop 24/7. 2FA is a major fucking headache that slows me down and wastes my time. I appreciate having it available, but I loathe being forced to use it.
2FA is great and I'm not against it. What I AM against is every single 2FA site wanting me to install its own app with their own TOTP implementation. So far I have Google Authenticator, Symantec VIP, Steam's one, and one from my bank. There is another site on which I would like to enable 2FA but that would need yet another app. Where do you draw the line? And yes I know that with some work I might be able to hack them together a bit closer but life's too short.
2FA sucks. It is poorly implemented. Either it is insanely inconvenient as hell. It relies on publicly acquired (by the site) information about me which clearly can be acquired by others with malicious intent. It asks the same questions all the other sites do so when one of them is hacked my answers are available (Unless they have been encrypted. How often not or with a weak easily hacked algorithm?) for them to grab my identity. https://krebsonsecurity.com/2015/12/2016-reality-lazy-authentication-still-the-norm/ The questions are often insanely obscure: The name of your 4th grade teacher? Or easy to find out: The name of the street you lived on ten years ago? My favorite: Your mother's maiden name? Like that isn't easily acquired.
Additionally, passwords are also lame. Sites with financial transactions I have conducted restrict maximum password length to 15 characters (very common). Restrict the password to alphanumeric or limited number of ASCII. Or allow a fairly large (up to 63 character) ASCII password, but will not allow cut and pasting in the re-type your password box when you first set up the password (or change it). Gosh thanks so much. Yes, I take the responsibility to use a password manager that (hopefully) randomly creates unique passwords of whatever length I specify. But sites make it impossible to use a secure password in the name of either their limiting storing space, incompetent coding or "for my security."
> My password has twenty five symbols. Be my guest
If the bad guys were specifically targetting you, they'd know enough now to put the HTTPS attack on the back burner and break out some of the more specific tools.
Chances are, they aren't specifically targetting you, so they keep fishing for passwords that are short enough to break, and profit from that. That you have a long password is a tip off to them that you may have other defences, so it'd be too costly to focus on you.
It's no different to having a strong front door lock. You either divert opportunistic crimes to your neighbours; or you cause the person seeking to specifically burgle you to look for other weak spots.
"It's no different to having a strong front door lock. You either divert opportunistic crimes to your neighbours; or you cause the person seeking to specifically burgle you to look for other weak spots."
Secure passwords are getting the norm now - that doesn't mean a thing, as it could be a facebook log-in or even some stupid games forum.
BUT, if you have the biggest fuck-off lock on your front door and garage, with security alarms and what not, THEN you have something to hide, and the criminals will be very, very interested in your property.
Question: Is everyone naïve when it comes to digital security? Answer: Probably.
Does anyone with reasonable digital knowledge not know that virtually nothing in society is really digitally secure? We pretend that it is to keep people from going into panic just like we pretend that governmental authorities can protect us from terrorism or violent crime. Stop and think for a minute and you will soon discover these beliefs are meritless. The reason that hackers are able to easily hack is because everything from the hardware to the O/S to the software that 99% of the world uses is insecure. It was never intended to be secure from the get go. Patches don't make it secure and never will. Companies make lots of money by trying to reduce the digital access points to data but it's hopeless for the most part except in very small instances that do not involve the use of the Internet or the commercial hardware/software and O/Ss in common use. Your reality for 2016 is that no one that you know is digitally secure even though they might believe they are.
Cheers.
Yawn. So what if they knew my password is 16 characters long? It will still be computationally infeasible to find it through a brute force search. As long as you use a password twelve or more characters long, has symbols, numbers, and capital letters, and must not have dictionary words, then it will be very difficult to attack. And if you use a good pseudorandom password generator then you're good to go.
One simple way to counter this ground-breaking attack is to use clientside scripting to hash the username and password on the browser before transmitting it. Then all credentials will have the same length. Problem solved.
> One simple way to counter this ground-breaking attack is to use clientside scripting to hash the username and password on the browser before transmitting it.
Yes - Let's use clientside security. Nothing has ever gone wrong with that mental-fuckery.
DAMN-IT there are some dumb fucks in this world!!!
Yes - Let's use clientside security. Nothing has ever gone wrong with that mental-fuckery.
Even better.. Lets go to some "trustworthy" source of fancy off-site/3rd party scripts just for this.. Like none of them would ever try to add something to harvest passwords....
Oh that I could upvote twice...
Being able to create strong passwords is one thing. Being able to recall them is another. And, being able to recall the relations between the accounts and the corresponding passwords is yet another.
At the root of the password headache is the cognitive phenomena called “interference of memory”, by which we cannot firmly remember more than 5 text passwords on average. What worries us is not the password, but the textual password. The textual memory is only a small part of what we remember. We could think of making use of the larger part of our memory that is less subject to interference of memory. More attention could be paid to the efforts of expanding the password system to include images, particularly KNOWN images, as well as conventional texts.
Incidentally, biometrics are dependent on passwords registered in case of false rejection in the cyber space. So are multi-factor authentications and ID federations like password-managers and single-sign-on services. And, in a world with passwords killed dead , we have no safe sleep. Passwords will stay with us for long.
Block based ciphers already use padding so the paper doesn't focus on these.
Yes, but with 64-bit blocks, that padding only increases the work factor by 8 at best, which is equivalent to only three more key bits. It's not a big improvement.
As with the proposals in other comments to add padding to the messages themselves, you're increasing the storage and computation requirements for the attacker - which is what security is all about, of course - but it's not a silver bullet.
Seriously, 2FA? This has not work for over 20 years, and is still useless today.. Why does nobody switch their brain on when passwords get hacked, and all flock directly to the fire from the fryingpan?
Here is how to solve security problems:
1. WORK OUT THE PROBLEM (hint - look at the threats).
2. FIX THE PROBLEM (hint - it needs to address the threats!!!!)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
