How long is your password? HTTPS Bicycle attack reveals that and more

Topic

New Reply

This isn’t good and this sort of attack seems to happen from time to time. Particularly with many websites restricting the length already to 15 characters max (and often alphanumeric or limited ASCII). I hate 2FA. It is a joke in its implementation. Almost always. I wish sites (and PC’s/personal password apps) would simply implement a 5 password tries, 5 min. lockout. That would stop most attacks using a library of possibilities.

How long is your password? HTTPS Bicycle attack reveals that and more

by John Leyden
The Register
Jan. 6, 2016

…. 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 – discovered by security researcher Guido Vranken (and summarised below) – refocuses attention on topics such as encryption, authentication, privacy and most specifically password security…. [url url="http://www.theregister.co.uk/2016/01/06/https_bicycle/"]Continue reading article here[/url]

Reply | Quote

Replies

I wish sites (and PC’s/personal password apps) would simply implement a 5 password tries, 5 min. lockout.

Many years ago I worked on Novell networks. You could set the number of password tries and the length of the lockout. I worked on systems with a 3 try limit and a 24hr (yes, 24hr) lockout.

Obviously this isn’t going to stop everything, and it doesn’t really apply to this particular situation. But it does surprise me that something like this is not a part of every password system out there. I got mixed up on my passwords at an investment company who changed their password rules to something really arcane and a week later it took me about 6 tries before I realize I had transposed two characters. No telling how many tries the system would have allowed.

Reply | Quote

Yes, I was a user on a fair number of systems with a 24 hour lockout after the 4th try. Ridiculous. Probably to give time to the IT guys to see who it was before access was regained. Of course back then passwords were alphanumeric, short, and often required changing every month or three with no old passwords allowed repeated. No wonder people wrote them down on their desk.

But yes, even a 5 min. lockout thwarts anyone with a password library hash. It just takes too much time. Knowing the actual length of the password used cuts out a lot of possibilities. As does knowing the rules of the passwords that are permitted.

Reply | Quote

…5 password tries, 5 min. lockout

I like your idea. It has been my experience that the “3 strikes and you’re out” settings are too restrictive. Lots of users will breach the limit just because they are confused or uncertain. I’ve successfully used systems, with no apparent loss of security, that allowed up to 9 tries.

Also, the short lockout time has a lot of merit. The real security exposure that the lockouts attempt to block are the configurations where automated attacks can attempt password combinations as fast as their connections will allow. However for a legitimate user who has simply locked themselves out, the lockout is simply an annoyance that will usually result in a call to the Help Desk. A 5 minute lockout raises the possibility they may not need to call.

Reply | Quote

5T5L (5 tries – 5-min lock out)
Now that’s customer service. Save corp. spending yet stop the auto-hacking.
You get my vote.

Even better: 6T3L

Customers are getting older, … and older. Seniors would clog the help system even at 5-min lock out!

Reply | Quote

The Bicycle attack is clever in that it looks at bits and pieces of plain-in-the-sight data, know their locations in relations to the ‘secret data’ (say, a password string). Then it knows the secret data’s ‘strength’ (say, the password length).
The author of the paper also provides a few solutions to ‘counter the attack’, such as sending only the hash of the password, and padding the password transmission with 1000 spaces or zeros, then sending it in hex (so be able to remove the padded spaces or zeros by the server, extracting the true encrypted password string).
The padding method foils the attempt to extracting the length of the password.

But, it must get to the password string in the transmission first.
Cleverly, by just looking at the sizes of the pages, etc., the password length could be ‘calculated’. Furthermore, the plain text before the password is so obvious, such as ‘Enter your Password’, etc.!!! It tellingly leaks what is next!

There are certain difficulties to hack this way, according to the paper. You must tie the UserID to the password, else it does not work.

Some log-in web pages have both ID and password in one single page. Not good. On the other hand, even in the past (and present), some (e.g. Verizon) require 2 web pages. Enter ID in the first page, then pops to another web page to enter password. That foils the attack, as ID and password are separate transmissions. The many in between transmissions make tying the two together extremely difficult … but possible. It’s another story …

The obvious way, easy IMHO, is that the web pages for ID and password should keep changing. Now the web page size is variable. That would foil this ‘size-calculation’ attack.
Today, quite a number of log-in web pages are like this. Unbeknownst to the web page owner, it foils this ‘future’ attack already. The owners just want to advertise or present different products daily/hourly or faster. The advertisement keeps changing on the log-in page. An example is eBay. Its web page size keeps changing because of the advertisement and product display.

Web surfers may also inadvertently foil this attack as well. Like me, I use No-script and Ad-block add-ons. The result is that the web page size will keep changing.
Anyway, great paper. Learn something everyday.

Reply | Quote