Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Encryption Security Your Rights Online

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!
This discussion has been archived. No new comments can be posted.

New HTTPS Bicycle Attack Reveals Details About Passwords From Encrypted Traffic

Comments Filter:
  • by Anonymous Coward

    Everyone knows only terrorists use bicycles. Good citizens should stick to unicycles.

  • by Sowelu ( 713889 ) on Wednesday January 06, 2016 @08:36PM (#51252969)

    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".

    • 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.

      • by mspohr ( 589790 )

        "I think this attack is probably going to be minimally useful at best, and even then only for very short, stupid passwords."

        ... which are already susceptible to simple brute force attacks.

        • very short, stupid passwords

          OK, everyone - time to update your passwords - "54321" is 4.400243 times better than "12345"
        • by Rob Y. ( 110975 )

          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?

      • by maugle ( 1369813 )
        It is still a very useful tool, though. As the GP pointed out, it allows for more effective use of computing resources by knowing in advance which passwords can and can not be feasibly cracked, and applying brute force attacks at only the crackable ones.
        • 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)

      by Anonymous Coward

      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.

      • 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"
        • 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.

        • by santiago ( 42242 )

          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.

    • Eh? If you know the password is 13 chars why would you bother guessing shorter passwords?

      • by 89cents ( 589228 )
        True, but this will save you very little. Think of all possible 12 character passwords as a 13 character password with a null character for the last character. If you have a character set of 80 characters, this will only save you 1/80th of the total possible password combinations.
    • by Anonymous Coward

      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.

    • by gweihir ( 88907 )

      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.

  • by guruevi ( 827432 ) <.eb.ebucgnikoms. .ta. .ive.> on Wednesday January 06, 2016 @08:55PM (#51253047) Homepage

    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.

    • by devman ( 1163205 )
      AES-GCM is derived from CTR mode. CTR mode turns a block cipher in to a keystream generator (thus a stream cipher). I haven't fully read the paper though, so I don't know whether this attack applies to block cipher used as stream ciphers.
  • How secure are the more modern search sites with perfect forward secrecy and proxy services? Thanks.
    • by Anonymous Coward

      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.

  • It's a good thing Guido discovered the need for padding when riding bicycles because you could fall and hurt your head.

  • The attacker needs to know the exact length of all the other data. That means they need all the cookie data being sent, etc.

    • 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.

      • 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

        • 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.

        • 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

    • 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

  • 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.

  • by PopeRatzo ( 965947 ) on Wednesday January 06, 2016 @09:52PM (#51253287) Journal

    I think this is taking the Internet of Things too far.

  • Client side hashing as a preventative measure?
    • 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.

  • 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

  • by Anonymous Coward

    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

  • 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.

  • Seems to me there's no such thing. Everything may be logged. Soviet Venona messages were eventually cracked due to one-time pads not being used only one time, but that wouldn't have happened without the traffic having been logged and kept for years. If quantum computers are created that can crack encryption we've used up until now, there's not much hope for anything used up to the present except true one-time pads. Perfect forward secrecy is when everybody who saw the message has died.
    • 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

He keeps differentiating, flying off on a tangent.

Working...