back to article For Foxit's sake: PDF editor biz breached, users' passwords among stolen data

Users of software house Foxit's free and paid-for products, including its popular PhantomPDF editor, may have fallen victim to a data breach – with stolen data including users' website passwords. Foxit admitted to the breach earlier today, stating that "third parties" had gained access to its My Account user data. That data …

  1. A random security guy

    At least 6 and at most 20 characters long

    In this day and age of unstructured data, 20 characters seems like a stupid upper limit. All they have to do is google minimum password strength and out pops 8 characters. For 20 characters to be truly effective, they need to be chosen randomly. A highly unlikely scenario.

    1. Archtech Silver badge

      Re: At least 6 and at most 20 characters long

      "And they're imposing a 20-character limit on new ones".

      Because, you know, hard drives don't grow on trees. Disk space is so expensive!

      1. dajames Silver badge
        Joke

        Re: At least 6 and at most 20 characters long

        Because, you know, hard drives don't grow on trees. Disk space is so expensive!

        Ah, yes, that's true -- I'd forgotten how much longer the SHA2-256 hash of a 40-character password is than that of a 20-character password!

      2. 9Rune5
        Coat

        Re: At least 6 and at most 20 characters long

        Disk space is so expensive

        You f00lz! Think of the extra bandwidth!

      3. Anonymous Coward
        Anonymous Coward

        Re: At least 6 and at most 20 characters long

        Because, you know, hard drives don't grow on trees. Disk space is so expensive!

        Not to mention all the color pixel it used on screen as text!

      4. Captain Scarlet Silver badge

        Re: At least 6 and at most 20 characters long

        It would annoy me as I set keypass to default to 32 characters (Not the hex preset, upper lower case with symbols)

    2. Roland6 Silver badge

      Re: At least 6 and at most 20 characters long

      What would the average job need a password longer than 20 characters when it is most likely that their email account password (ie. password reset tool) is 'Password1' ?

      1. FlamingDeath Bronze badge

        Re: At least 6 and at most 20 characters long

        They should also definitely force the user to type in every last letter, number & symbol, because allowing copy and paste when creating passwords is a security risk /Sarcasm

        Looking at you PayPal

        1. Roland6 Silver badge

          Re: At least 6 and at most 20 characters long

          Sometimes what we say in sarcasm contains truth.

          If we were to force Joe public to use say 20 character passwords, I suspect we will see many of the form:

          Password1+Password2! ie. a very simple phrase that can be remembered and easily keyed.

          It is going to be interesting to see the effect the banks enhanced online transaction security protocol is going to impact online purchasing habits, at some point people will simply find going to the cash machine or writing a cheque less hassle...

    3. Robert Carnegie Silver badge

      Actually at least 8 and at most 20 characters long

      ti sseug lliw eno on

      8 to 20, hmm. Our penetration testers popped my mostly random password, that was... towards the shorter end of that length range. So, 8 characters is officially not enough any more.

      If I go for more random letters in a fixed pattern (when I have to type out the sxddxngxthxng and remember it), is it OK to reveal the pattern as a helpful example? Best not, probably. The main thing is, I just remember x letters of it at a time. Type, pause, think, type...

  2. Steve Aubrey
    FAIL

    'if Foxit's password cache was indeed neither salted nor hashed, this could be severely problematic for its customers.'

    And, presumably, for the firm itself. That's lawsuit territory these days.

    1. Christoph Silver badge

      If the passwords were not salted and hashed, they have major problems. Anyone not doing that in 2019 should be fired for incompetence.

      If the passwords are salted and hashed then what is stored is the hash which is a fixed length. Therefore imposing an arbitrary password length limit is completely pointless. You need some limit on buffer length and calculation time, but 20 characters?

      1. Michael Wojcik Silver badge

        Hell, in 2019 I'm pretty suspicious of anyone not using Argon2, bcrypt, or scrypt (or maybe PBKDF2). Even using SHA-256 is suspect. We've had good scale-resistant password-hashing functions for years now; it's time for competent organizations to be using them.

  3. Woodnag

    "20 characters seems like a stupid upper limit".

    It's the limit for BitLocker on Win 8.1 at least.

    1. Tom Chiverton 1

      Win 8.1 isn't supported any more

      1. fnusnu

        “Windows 8.1 falls under the same lifecycle policy as Windows 8, and will reach end of Mainstream Support on January 9, 2018, and end of Extended Support on January 10, 2023".

    2. Michael Wojcik Silver badge

      It's the limit for BitLocker on Win 8.1 at least.

      Non-responsive. Microsoft's ill-conceived policy does not justify Foxit's.

      Also, they're not comparable. BitLocker and Foxit's customer account system operate in different environments and have different threat models.

  4. Anonymous Coward
    Anonymous Coward

    If they're going to hash the password anyway (as they SHOULD be) why have ANY upper limit?

    1. Will Godfrey Silver badge
      Facepalm

      It won't make any difference

      Large numbers of numpties will use exactly 8 characters. The first will be a capital, the seventh will be an underscore or hyphen, and the last will be zero or one.

      1. Anonymous Coward
        Anonymous Coward

        Re: It won't make any difference

        Drat. Rumbled.

      2. Richard 12 Silver badge

        Re: It won't make any difference

        Hah! Mine is 2!

        Oh. Crap.

        1. VinceH
          Joke

          Re: It won't make any difference

          I see what you did there, you tried to fool us with the factorial symbol - but that still comes out as 2. Cunning, but it didn't work.

      3. Michael Wojcik Silver badge

        Re: It won't make any difference

        Large numbers of numpties will use exactly 8 characters

        So what? Why penalize other users?

      4. Anonymous Coward
        Anonymous Coward

        Re: It won't make any difference

        Most will be a persons name, town, city or country. Then onto sports teams and TV shows.

        Known from pen testing my orgs AD.

    2. John Miles

      why have ANY upper limit?

      Because if you don't then you will likely be opening yourself up for DoS attacks where someone pushes a few million characters into password field and because password hashing is designed to be slow it will take a lot of resources on the sever if your get a lot of connections passing in very long password.

      However it should be possible to find a sensible limit above 20 characters (bcrypt I believe only handles 72 bytes for hashing)

      1. <script>alert('the register');</script>

        Re: why have ANY upper limit?

        password_hash(hash('sha256', $_POST['password']));

        done

        1. s2bu

          Re: why have ANY upper limit?

          That's a horrible way to do password hashing. BAD BAD BAD!

          1. <script>alert('the register');</script>

            Re: why have ANY upper limit?

            It is pretty standard for PHP.

            Bcrypt has a 72 character limit.

            Password_hash is an actual function which in built salt.

            Step aside...

            1. Michael Wojcik Silver badge

              Re: why have ANY upper limit?

              It is pretty standard for PHP.

              To a first approximation, this is a synonym for "that's a horrible way to do it".

              Since password_hash hashes the input, there's little point in taking the SHA-256 hash of it first. Even if the submitted passphrase is > 72 characters and is truncated, 72 characters from a decent character set has around 430 bits of entropy, so you're better off letting it truncate.

              If you really want to hash first, you should be using hash_hmac with a hard-coded or configurable secret (sometimes called "pepper"), per the NIST recommendations; that makes rainbow tables for weak passwords more expensive.

              If you don't specify an algorithm identifier, you get whatever your PHP version has picked for the default. Currently that's bcrypt; Argon2 would be a better choice.

      2. Robert Carnegie Silver badge

        Re: why have ANY upper limit?

        Alphanumeric has 36 possible values per symbol, so just more than 5 bits. Alpha only, which I prefer for typing, has a bit less (26 values in plain ASCII, not counting case). Presumably, padding the length with random characters to be somewhat more than the number of bits in the hash of the password, will mean that your position in the hashed space is also pretty well random. And so adding more characters is not useful... unless and until they switch to a longer, larger space of hashed values.

        1. Michael Wojcik Silver badge

          Re: why have ANY upper limit?

          This argument is rather baffling. Any password-verifier mechanism using a decent digest (aka "hash") will be storing enough entropy to represent around 50 alphanumeric characters.

          The "position in the hashed space" is irrelevant. Password verifiers created with a competent algorithm aren't broken by analysis; they're broken by brute force, using precomputed values (when no salt was used, or when the salt and preimage length are short enough to make rainbow tables feasible) and/or parallel trials with a (mutating) dictionary of short and common passwords.

          So longer passphrases are very much useful, assuming a competent password-verifier mechanism.

          And we don't know what Foxit are doing. They may have a competent verifier mechanism with an incompetent front end (thus the 20-character limit). They may have a competent verifier mechanism and front end with an incompetent policy for no good reason. They may have an incompetent mechanism, such as an unsalted hash or worse.

          1. Robert Carnegie Silver badge

            Re: why have ANY upper limit?

            Well, properly done, the password isn't stored. Only the hash of the password is stored. So, picking a password is just equivalent to picking one random number a the hashed password value.

            For instance, suppose the hash of the password is a 32 bit integer, and the password can be a 36 bit integer. Then in fact the password that I actually use id not the only password input that generates that hash. There are 15 others, and inputting any of the 16 will be accepted as if it was my password.

            Now, a thoughtful attacker still will try out "password" and "123456" first, because those might be the actual password.

            32 bits is 4 bytes or, roughly speaking, 4 ASCII characters, but if that was also the password length then "abcd" is still likelier for someone to use, unwisely, than "J£@2". However, the set of all 8 character hexadecimal expressions will map into all 4 byte values if thr hadh works well. So for instance "61626364" ... well, that's "abcd" again, but better.

            If you type octal triplets then a password format of 012 345 670 123, with random numerals 0 to 7, may be memorable one triplet at a time, and convenient to type, and it has 2^36 combinations, so it includes basically all of the 32-bit hash values. So adding more digits than that to this password does not increase protection.

            But of course it's a false assumption that a password hash is 32 bits... we hope. Today, it needs to be substantially longer than that. And so a password length and format that exhausts the possible hash values is much longer too. But such a limit still exists, so your password may be the entire second act of Hamlet but its hash happens to be the same as "abcd", so I can just type that and crack your account. What are the chances eh? True - extremely unlikely, but there will be much shorter duplicates. And the curse of long passwords, mistyping when you want to log in, is worse for longer.

  5. Foxglove
    Coat

    Please use correct terminology.

    'The Register has asked Foxit's people'

    We all know 'reached out' is the correct parlance, not 'asked'.

    >>>

  6. Cavehomme_ Bronze badge

    Only 20 characters?

    Shock! Horror!

    Isn't this secure enough:

    pM$3Tq#8Izg5%DTin$VD

    ???

    Bollox to the naysayers.

    1. Tromos
      Joke

      Isn't this secure enough?

      It was, until you splashed it all over el Reg!

    2. Anonymous Coward
      Anonymous Coward

      Didn't you read the first commenter's helpful remarks?

      "For 20 characters to be truly effective, they need to be chosen randomly. A highly unlikely scenario."

      We're talking normal people here, and not using password managers. Identify the real deficiency, okay?

  7. fobobob

    Password

    Aaaaaaaaaaaaaaaaaaa!

    Strong enough.

  8. Phil Endecott Silver badge

    Limits like “max 20 characters” seem designed to break password managers; I think mine suggests 24-ish.

    This may be deliberate in some cases, e.g. banks who really want you to memorise a password rather than storing it in any way.

    1. Paul Crawford Silver badge

      Deliberate?

      While it might be nice to thing that some are trying to get you to memorise a password, the reality is the explanation is much more likely to be incompetence. Stupid password rules = post it notes for most.

      As many have already mentioned, there is no excuse for not allowing a reasonable upper length such as 128 bytes or whatever. A 20-character limit is something most likely down to an idiot web designer setting an input field length, you see the same in other places (e.g. names which is a bummer if you are Greek or it is a verbose company name, etc)

      1. Roland6 Silver badge

        Re: Deliberate?

        >A 20-character limit is something most likely down to an idiot web designer setting an input field length

        Really, have you written code and "looked under the hood" and understand how that infinite length field is actually handled?

        I suggest for the average joe, getting them to use passwords longer than 8 characters is an achievement.

        Also perhaps it is worth considering just what the website is storing - perhaps FoxIt are implying their service isn't for classified documents, just for your run-of-the-mill inconsequential stuff.

      2. simonlb Silver badge
        Facepalm

        Re: Deliberate?

        'web designer setting an input field length'

        How about:

        Company rolls out a new internal system.

        First time login is with temporary password and you set a new password of between 8 and 20 characters

        Subsequently, only some users can then login but most cannot and receive an incorrect password message when trying to login.

        After large number of users log fault tickets, it emerges that even though the password field on the login screen can accommodate up to 20 characters, any entered password is being truncated to the first 8 characters entered before being checked against the users account, so only users who set an 8 character password could ever login.

        Issue was quickly fixed, but someone got their arse kicked over it.

    2. dajames Silver badge

      This may be deliberate in some cases, e.g. banks who really want you to memorise a password rather than storing it in any way.

      Storing passwords (securely, of course) is a good idea, and I think most banks would enourage it.

      Storing passwords in some fashion that allows them to be cut-and-pasted rather than typed -- that is: storing them on the device from which the authentication is taking place -- is more questionable, because a password stored on the device could be captured by malware and used again without the user's knowledge.

      Very long, very arbitrary, passwords are almost impossible to remember and retype correctly, and so are an indication that an on-device password manager is being used. Banks might reasonably object to that.

      1. Michael Wojcik Silver badge

        an indication that an on-device password manager is being used. Banks might reasonably object to that.

        Banks might object to the use of password managers. They cannot do so "reasonably", as there are no reasonable objections to them, from the banks' position. The attack tree with a password manager is a considerable improvement for the defender over the attack tree without one.

        Password managers introduce new failure modes, but nearly all of them affect the user, not the resource. Those that do affect the resource are highly unlikely and thus have a low relative risk.

  9. Bill Gray

    Storing passwords in plain text?

    Whenever I see a 20-character upper limit, I assume passwords are stored in plain text. I could see an upper limit of, say, 500 characters to avoid DoS attacks or efforts to overflow buffers. But those smaller limits look suspiciously as if somebody wanted the unhashed password to fit into their database.

    Am I wrong? Is there actually a good reason to insist on a lowish upper limit?

    For that matter, I make a similar assumption when I'm told my password can't contain spaces (or commas). That suggests to me that their database would interpret my password as two or more fields. A password should be able to hold any Unicode text; after all, once hashed, it's a string of hex digits anyway.

    My preference would be that my password be salted and hashed _in the browser_. This doesn't remove the need to use https or for salting/hashing to occur at the server end, but it does mean that I have good reason to think that the site I'm communicating with never sees my unhashed password and cannot, no matter how badly the security is botched, leak my unhashed password. (Which provides them with a degree of security as well, and an excellent defense if accused of leaking passwords : "It wasn't us what done it; we couldn't have done it had we wanted to.")

    It also, of course, means that if I wanted a gigabyte-long password, it'd be fine. It'll just get salted and hashed and the same number of bytes get sent to the server.

    1. dajames Silver badge

      Re: Storing passwords in plain text?

      A password should be able to hold any Unicode text; after all, once hashed, it's a string of hex digits anyway.

      Where passwords are restricted to a limited character set that generally has nothing to do with password security, and a lot to do with the practicalities of entering passwords into a variety of devices that operate with different character sets and/or code pages.

      Many years ago, when I was still at University, I thought I was very clever at having selected a "strong" password -- it was pretty strong for the time, it included upper and lower case letters and non-alphabetic characters (I don't remember which) -- and I recommended that my colleagues do the same (if only to stop other students from logging in to our accounts and using our departmental line-printer paper allowance).

      Imagine my embarrassment at trying to log in to a Tektronix graphics terminal to get a quick preview of a graph I had generated ... and finding that it didn't support lower-case letters!

      1. Bill Gray

        Re: Storing passwords in plain text?

        You're partly right -- I'd like to be able to enter a password in Russian, for example, but would have to accept that I don't have a way to enter Russian on my phone. For some sites, I can accept that limitation, because I only access them from a desktop or laptop where swapped keyboard layouts are a hotkey away.

        The cases I'm thinking of, though, are more along the lines of not letting me enter spaces, quotation marks, or commas. To me, those restrictions smell of storing passwords in plain text, not of a well-intentioned effort to keep me from locking myself out of access from my phone (or Tektronix terminal).

      2. J.G.Harston Silver badge

        Re: Storing passwords in plain text?

        "a lot to do with the practicalities of entering passwords into a variety of devices that operate with different character sets and/or code pages."

        Such as setting a BCrypt/BitLocker password including # or @, but the boot-up password screen switches to/from US/UK keyboard layout without telling you and without you knowing that under those *******s you're entering \ and ".

    2. brotherelf
      Boffin

      Re: Storing passwords in plain text?

      I hate to tell you, but there's protocols that are actually somewhat underspecified in terms of what encoding the password should be in, effectively reducing you to 7bit ASCII as common denominator. (HTTP Auth, I'm looking at you.)

      And your hash-in-the browser scheme is somewhat flawed: whatever you give the service to recognize you by, that's de facto the password. The server can't tell if you use 2000 rounds of bcrypt every time to derive it from your first pet's maiden name or if it's just wgo4387gwheo34 by chance and you send that directly. Yes, you can build something like "Server tells the client to run X iterations, server runs N-X iterations and only has the N-iteration hash on file", which is basically challenge-response, but frankly, the answer to "the service has something like my password" is public key crypto, and that's even baked into TLS (client auth), and HTML5 had extra support for that by way of the keygen element, but browsers are actively removing those capabilities, and the UI was always pretty horrible, and server-side, it was always a bit of a dark art.

      1. Bill Gray

        Re: Storing passwords in plain text?

        Hmmm... Maybe I'm missing something, but it sounds to me as if you're addressing a different set of issues.

        My thought is as follows. For randomsite.com, my password is my first pet's maiden name, ⅔‫‫ש‬ל‬фщ®куè (I used to pick some odd names for my pets). Within the browser, this is salted/hashed and we get, say, DEADBEEF5318008, all ASCII hex digits. That's what gets passed to randomsite.com. They don't know how long my password is, or if it has non-ASCII characters.

        Because I can see the script, I can verify that randomsite.com doesn't know my pet's name; they just know that when salted/hashed, it's DEADBEEF5318008. They really ought to salt/hash it, store the result, and forget about DEADBEEF5318008. But I may not trust them. Or they may screw up.

        So then they get hacked. World+dog promptly checks my banking and e-mail and other accounts to see if I used that password elsewhere. Which, of course, I did (doesn't everybody?) But -- because randomsite.com never knew my real password and only saw DEADBEEF5318008, and nobody else knows about my beloved pet ⅔‫‫ש‬ל‬фщ®куè -- they're out of luck.

        They can access my randomsite.org account, though. Unless randomsite.com isn't run by bozos after all, and _did_ take the DEADBEEF5318008 I sent them and salted/hashed it.

        But this scheme only protects against password re-use (and allows me to use a non-ASCII password). randomsite.com still ought to use https and otherwise follow best practices.

        1. Anonymous Coward
          Anonymous Coward

          Re: That seems reasonable.

          They could try a rainbow table or some other brute force compute to get your pet name, but would be very resource intensive, and often not worth it before the heat death of the universe.

          Nowadays, they just malware onto the users pc, or hack the website backend and pwn it all it seems. :(

        2. Michael Wojcik Silver badge

          Re: Storing passwords in plain text?

          There are cryptographic protocols for verifiers that don't expose the secret to the verifying party. SRP is the best known, but there are also PAK variants, for example. The identity-asserting party (the browser in this case) completes a zero-knowledge proof that it holds the secret in response to challenges from the authenticating party (the server). The authenticating party just has the information it needs to conduct the ZKP protocol; nothing it holds or receives can be used to impersonate the holder of the secret, short of brute-forcing the secret.

          That's safer and more elegant than having the browser hash or otherwise mutate the user's input. In particular, a passive MITM who can intercept the ZKP messages can't use them to subsequently impersonate the user.

          One problem with doing SRP in the browser is that you have to trust the SRP implementation, and for that matter the browser, so the incremental strength over HTTPS is small. On top of that you have the usual network problem: it's not advantageous for browser manufacturers to add it until a decent number of servers support it, and it's not advantageous for servers to support it until a decent number of users are prepared to use it.

          Hell, how often do you see HTTP Digest Authentication used in the wild? And that's been around for 20 years.

  10. Velv Silver badge
    Boffin

    Unique passwords...

    Unique passwords are no longer sufficient. Safer to use unique usernames as well as unique passwords.

    Get your own domain name so you can set up unique email addresses every time you register for anything.

  11. The Central Scrutinizer

    And stupid is as stupid does.

    "Foxit is also enforcing password resets on its users with a hard 20-character length limit, saying this would make new passwords "strong enough".

    1. Michael Wojcik Silver badge

      Re: And stupid is as stupid does.

      It's a red flag. A clear sign that the organization either does not understand security, or doesn't care.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019