Last week, I tried to register for a service and was really surprised by a password limit of 16 characters. Why on earth yould you impose such strict limits? Never heard of correct horse battery staple?

  • faltryka@lemmy.world
    link
    fedilink
    arrow-up
    147
    arrow-down
    5
    ·
    3 months ago

    This is my biggest pet peeve. Password policies are largely mired in inaccurate conventional wisdom, even though we have good guidance docs from NIST on this.

    Frustrating poor policy configs aside, this max length is a huge red flag, basically they are admitting that they store your password in plan text and aren’t hashing like they should be.

    If a company tells you your password has a maximum length, they are untrustable with anything important.

    • cron@feddit.orgOP
      link
      fedilink
      arrow-up
      88
      ·
      3 months ago

      Oh I had the same thought. Whoever limits password length probably has many other shitty security practices.

      • cron@feddit.orgOP
        link
        fedilink
        arrow-up
        58
        arrow-down
        1
        ·
        3 months ago

        OWASP recommendation is to allow 64 chars at least:

        Maximum password length should be at least 64 characters to allow passphrases (NIST SP800-63B). Note that certain implementations of hashing algorithms may cause long password denial of service.

        The lemmy-UI limit is reasonably close and as everything is open source, we can verifiy that it does hash the password before storing it in the database.

        There is a github issue, too.

      • faltryka@lemmy.world
        link
        fedilink
        arrow-up
        15
        arrow-down
        1
        ·
        3 months ago

        It being open source helps because we can confirm it’s not being mishandled, but it’s generally arbitrary to enforce password max lengths beyond avoiding malicious bandwidth or compute usage in extreme cases.

    • unmagical@lemmy.ml
      link
      fedilink
      arrow-up
      20
      ·
      3 months ago

      If a company tells you your password has a maximumn length, they are untrustable with anything important.

      I would add if they require a short “maximum length.” There’s no reason to allow someone to use the entirety of Moby Dick as their password, so a reasonable limit can be set. That’s not 16 characters, but you probably don’t need to accept more than 1024 anyway.

        • phcorcoran@lemmy.world
          link
          fedilink
          arrow-up
          12
          ·
          3 months ago

          Sure but if my password is the entire lord of the rings trilogy as a string, hashing that would consume some resources

        • unmagical@lemmy.ml
          link
          fedilink
          arrow-up
          5
          ·
          3 months ago

          Of course, but if you’re paying for network and processing costs you might as well cap it at something secure and reasonable. No sense in leaving that unbounded when there’s no benefit over a lengthy cap and there are potentially drawbacks from someone seeing if they can use the entirety of Wikipedia as their password.

          • DaPorkchop_@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            3 months ago

            You can also hash it on the client-side, then the server-side network and processing costs are fixed because every password will be transmitted using same number of bytes

            • unmagical@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              3 months ago

              You still need to deal with that on the server. The client you build and provide could just truncate the input, but end users can pick their clients so the problem still remains.

            • Valmond@lemmy.world
              link
              fedilink
              arrow-up
              2
              arrow-down
              1
              ·
              3 months ago

              That would take care of it, you do nead to salt & hash it again server side ofc.

        • frezik@midwest.social
          link
          fedilink
          arrow-up
          2
          ·
          3 months ago

          Bcrypt and scrypt functionally truncate it to 72 chars.

          There’s bandwidth and ram reasons to put some kind of upper limit. 1024 is already kinda silly.

      • Revan343@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        you probably don’t need to accept more than 1024 anyway.

        OWASP recommends allowing at least 64 characters. That would cover all of my passphrases, including the ones that are entire sentences

      • AA5B@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        I wonder if a lot of it is someone using their personal experience and saying “just a little bigger ought to cover it”

        When I used my own passwords, I rarely used more than 12 characters, so that should be enough

        All the password generators I’ve used default to about 24 chars, so 30 ought to be enough for anyone

    • clearedtoland@lemmy.world
      link
      fedilink
      English
      arrow-up
      14
      ·
      3 months ago

      The number of government websites that I’ve encountered with this “limitation.” Even more frustrating when it’s not described upfront in the parameters or just results in an uncaught error that reloads the page with no error message.

    • chameleon@fedia.io
      link
      fedilink
      arrow-up
      10
      ·
      3 months ago

      bcrypt has a maximum password length of 56 to 72 bytes and while it’s not today’s preferred algo for new stuff, it’s still completely fine and widely used.

      • DaPorkchop_@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        3 months ago

        Wait, really? I always thought bcrypt was just a general-purpose hash algorithm, never realized that it had an upper data size limit like that.

    • primrosepathspeedrun@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      3 months ago

      also, if they think a strong password is only about types of characters. a dozen words from as many languages and 5+alphabets is just as good!

      its to the point I don’t bother remembering my passwords anymore, because this bullshit makes user-memorable-hard-to-machine-guess passwords impossible.

    • MotoAsh@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      12
      ·
      edit-2
      3 months ago

      “If a company tells you your password has a maximum length…”

      Uhhh no. Not at all. What so ever. Period. Many have a limit for technical reasons because hashing passwords expands their character count greatly. Many websites store their passwords in specific database columns that themselves have a limit that the hashing algorithm quickly expands passwords out to.

      If you plan your DB schema with a column limit in mind for fast processing, some limits produce effectively shorter password limits than you might expect. EVERYONE has column limits at least to prevent attacks via huge passwords, so a limit on a password can be a good sign they’re doing things correctly and aren’t going to be DDOS’d via login calls that can easily crush CPUs of nonspecialized servers.

      • wer2@lemm.ee
        link
        fedilink
        arrow-up
        16
        arrow-down
        1
        ·
        3 months ago

        It doesn’t matter the input size, it hashes down to the same length. It does increase the CPU time, but not the storage space. If the hashing is done on the client side (pre-transmission), then the server has no extra cost.

        For example, the hash of a Linux ISO isn’t 10 pages long. If you SHA-256 something, it always results in 256 bits of output.

        On the other hand, base 64-ing something does get longer as the input grows.

        • redxef@scribe.disroot.org
          link
          fedilink
          arrow-up
          3
          ·
          3 months ago

          Hashing on the client side is as secure as not hashing at all, an attacker can just send the hashes, since they control the client code.

          • wer2@lemm.ee
            link
            fedilink
            arrow-up
            2
            ·
            3 months ago

            Hashing is more about obscuring the password if the database gets compromised. I guess they could send 2^256 or 2^512 passwords guesses, but at that point you probably have bigger issues.

            • redxef@scribe.disroot.org
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              3 months ago

              It’s more about when a database gets leaked. They then don’t even have to put in the effort of trying to match hashes to passwords. And that’s what hashing a password protects against, when done correctly.

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        6
        arrow-down
        2
        ·
        3 months ago

        Just in case someone runs across this and doesn’t notice the downvotes, the parent post is full of inaccuracies and bad assumptions. Don’t base anything on it.

        • frezik@midwest.social
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          3 months ago

          The hash isn’t at all secure when you do that, but don’t worry too much about it. GP’s thinking about how things work is laughably bad and can’t be buried in enough downvotes.

            • frezik@midwest.social
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              3 months ago

              The Wikipedia article is probably a good place to start: https://en.wikipedia.org/wiki/Cryptographic_hash_function

              Though I’d say this isn’t something you read directly, but rather understand by going through cryptographic security as a whole.

              To keep it short, cryptographic hashes make a few guarantees. A single bit change in the input will cause a drastic change in the output. Due to the birthday problem, the length needs to be double the length of a block cipher key to provide equivalent security. And a few others. When you chop it down, you potentially undermine all the security guarantees that academics worked very hard to analyze.

              Even a small change would require going to a lot of work to make sure you didn’t break something. And when you’ve read up on cryptography in general and understand it, this tends to be an automatic reflex.

              None of which really matters. GP’s big assumption is that the hash size grows with input size, which is not true. Hash size stays fixed no matter the input.

  • akilou@sh.itjust.works
    link
    fedilink
    arrow-up
    61
    ·
    3 months ago

    I had to make an account the other day with the absolute worst password requirements I’ve ever seen:

  • paris@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    56
    ·
    edit-2
    3 months ago

    The worst is when it either won’t tell you what the character limit is so you have to just keep lowering it and retrying until it finally works, or when the infrastructure for signing up has a different character limit than the infrastructure for logging in, so you can sign up with a long password but can’t actually sign in with it. I once encountered a website that had this issue for both the password AND username so I had to change my password and then contact support to change my username. Absurd.

    • Nicadimos@lemmy.ml
      link
      fedilink
      arrow-up
      18
      ·
      3 months ago

      I used to manage a system that had a longer character limit on the creation than in the sign in. To fix it, they just let you type in more characters when you signed in but only validated the first 8 anyway. 🤦‍♂️

    • CoggyMcFee@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      3 months ago

      I used a service that had password validation on the “current password” field when you update your password. My password had stopped being valid due to a change in their password policy, but I couldn’t fix it because the “update password” form kept saying my current password was invalid. I know — you told me to change it!!!

    • absGeekNZ@lemmy.nz
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 months ago

      I have had this before, I was so confused for a while.

      Made account used my password manager, so I knew the password was correct, went around the loop a few times of “forgot password”; finally shortened form 25 to 16 characters and it just worked.

    • nocturne@sopuli.xyz
      link
      fedilink
      arrow-up
      29
      ·
      3 months ago

      Mine does not allow spaces. They used to use a 4 digit pin as 2FA. Not a new pin you got every time you logged in, the same 4 digit pin.

    • cynar@lemmy.world
      link
      fedilink
      English
      arrow-up
      15
      ·
      3 months ago

      A lot of bank computing is a complete clusterf@#k. Getting even basic changes and bug fixes requires it being signed off on by various regulators and committees. Apparently, 18 months for a 1 line change is normal. This has ended up with layers of new work being frankensteined onto older systems. E.g. Internet banking, for a long time, physically printed checks, via an automated machine, posted them, and then had them read in, via an automated machine. Hence why Internet bank transfers took 2-3 days.

      I had issues with my banks truncating my password a while back. It only looked at the first 8 characters.

    • AlecSadler@sh.itjust.works
      link
      fedilink
      arrow-up
      11
      ·
      3 months ago

      One of my past banks used to be case-insensitive. They aren’t anymore (as far as I know). Their name starts with Key and ends with Bank.

      • ChickenLadyLovesLife@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 months ago

        My bank got busted a few years ago for cheating customers using their coin-counting machines. Literally nickel-and-dimed their own customers. They removed the machines and just threw loose cloth over the empty spaces - an ongoing testament to their shame, if they could feel shame, which they can’t. Out of sheer laziness I’m still with them.

        • SkunkWorkz@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          3 months ago

          In my country all banks just use, instead of a username, the IBAN plus bank card serial number and they give their clients a hardware token that generates one time passwords. The client inserts their bank card into the hardware token then enter their PIN and gets the OTP to login. And when the client wants to make a transfer the bank generates a code that the client has to enter into the hardware token after entering their PIN to generate an OTP which the client uses to confirm the transfer. And if the client has the bank app installed on their phone the bank website generates a QR code which the client can scan with the app and then the client can login with their biometrics. Of course the client has to activate the app with the hardware token first.

          This isn’t that much different from a username, password plus 2FA. But this way it takes out the weakness that is the client. This prevents the client from using an easy password or use a username and password that they use everywhere else. Old people don’t write down their password anywhere since there is no password. But they know their PIN by heart since they use it all their life. And it doesn’t rely on apps or SMS for 2FA. So people without a smartphone or even a mobile phone can still use it. Keyloggers are useless since the PIN is entered on the hardware token. Sure a sophisticated con is still possible but thefts like these https://appleinsider.com/articles/23/12/20/how-a-brazen-passcode-thief-used-stolen-iphones-to-rob-2-million where the thieves can drain a bank account if they just steal the phone and phone’s passcode and reset the 2FA are impossible.

          The biggest weakness is ofcourse that if someone knows your PIN and obtains your bank card they can enter your bank account online. So the same security measure still applies with this that you should open a savings account at a different bank than your checking account.

          • smeg
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 months ago

            I’ve seen plenty of UK banks use these card readers to authenticate transfers, but never just to log in

            The biggest weakness is ofcourse that if someone knows your PIN and obtains your bank card they can enter your bank account online

            So essentially it is 2FA, but the password is short enough to brute-force?

              • smeg
                link
                fedilink
                English
                arrow-up
                1
                ·
                3 months ago

                I assumed as the card readers and cards are both offline devices they wouldn’t have a way to do this, are card blocks local in general?

                • SkunkWorkz@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  3 months ago

                  Modern cards have a chip inside them that’s basically a very tiny computer. It can check how many times the pin was incorrect.

  • Lycist@lemmy.world
    link
    fedilink
    arrow-up
    40
    ·
    3 months ago

    Its even better when they don’t tell you that your password is too long, and they truncate it somewhere unknown.

    Tried a randomgen 32 character password at the local sheriff’s office. Copy and pasted it directly out of my password manager into the password creation field so I know I didn’t typo it and when I tried to login it wouldn’t work. Took me a bit of troubleshooting to figure out what happened.

      • Zorsith@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        6
        ·
        3 months ago

        Ive seen an account creation or password reset that let’s you do any length password, but the actual login page has a character limit.

    • wreckedcarzz@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 months ago

      That happens all the fucking time, and it’s infuriating. Most recent example was with Kagi, which I eventually found out had a max of 72, truncated, no warning. I bitched out their support and they were like ‘nbd, and it should have warned you’ and I’m like ‘nope, no warning at all’ which means they didn’t bother checking if a warning actually showed or prevented the input, just ‘I wrote it so we must be good’.

      They claim to have fixed this, but ugh. Took me a half an hour, and I started with the suspicion that it was being truncated. Test your shit if you’re going to be stupid, people.

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        Bcrypt and scrypt have a limit of 72 chars, so it’s probably that. Implementations can work around it by putting the password through a pre-hash, but most don’t bother. There are tons of reasonably secure password storage systems with that limit.

      • Rogue
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        What are the benefits of a password greater than 72 characters? How high do you try to go?

        • AA5B@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          3 months ago

          The longer it is, the harder for anyone to guess, write down, remember, or brute force. For that long a password, someone can actually see my password and then have effectively zero chance of being able to use it.

          But maybe it’s more a ”why not?” In one side it’s generated so you can use it equally well, and in the other side it should be hashed to a standard length so they should be able to manage it equally well.

          • frezik@midwest.social
            link
            fedilink
            arrow-up
            1
            ·
            3 months ago

            When I did the math with a reasonable list of alphanums and symbols on a US standard keyboard, a 40 char randomly generated password had equivalent security to a 256 but block cipher key. Describing the difficulty in brute forcing that starts with the phrase “assume you can convert all the energy from a supernova at 100% efficiency into a thermodynamiclly perfect computer”. A roundabout way of saying impossible.

            40 chars random is already overkill.

  • youngalfred@lemm.ee
    link
    fedilink
    arrow-up
    39
    ·
    3 months ago

    A prominent Australian bank has these requirements:

    For Internet Banking, your password must be six to eight characters long.

    To improve security, it should:

    contain both numbers and letters.
    include upper and lower-case letters (your password is case sensitive).

    • smeg
      link
      fedilink
      English
      arrow-up
      10
      ·
      3 months ago

      8 character max means they’re running it on a mainframe I think, though I don’t know enough about mainframes to know if this is a normal level of bad or really bad

      • Rhaedas@fedia.io
        link
        fedilink
        arrow-up
        7
        ·
        3 months ago

        Could be (probably still is) running COBOL. It’s a combination of “if it works and costs money to upgrade, why change” but mostly “if we migrate one thing it will break five other things”.

        • smeg
          link
          fedilink
          English
          arrow-up
          1
          ·
          3 months ago

          Yep, that sounds like old bank tech to me

  • lseif@sopuli.xyz
    link
    fedilink
    arrow-up
    34
    arrow-down
    1
    ·
    3 months ago

    worst i’ve seen is 8 characters. precisely 8 characters, no more no less… it was for a bank …

    • Dwemthy (he/him)@lemdro.id
      link
      fedilink
      English
      arrow-up
      16
      ·
      3 months ago

      A major US bank that I used to use has case insensitive passwords, found that out one day when I noticed caps lock was on after logging in with no trouble

      • viking@infosec.pub
        link
        fedilink
        arrow-up
        12
        ·
        3 months ago

        Makes you wonder if they store the password in plain text, or convert to lower key during your first input so it’s at least hashed. I wouldn’t be surprised if it’s not.

        • JustAnotherRando@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          3 months ago

          I don’t think it could be hashed if it is case insensitive. It’s fairly early so I may be misremembering but I’m not aware of any hashing algo that ignores case.

          Edit: Ah, actually they could be storing the password as a hash, but they would probably have to do like a password. ToLower() call or something where they morphed the string before checking… The thought of which just makes me shudder.

    • Donkter@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      3 months ago

      The fact that it was a power of 2 makes me suspect lazy coding. That bank didn’t pay its programmers well enough.

  • MisterFrog@lemmy.world
    link
    fedilink
    arrow-up
    32
    ·
    3 months ago

    I got this from a bank. A BANK. Not only was it limited to 12 characters. THEY ALSO LIMITED THE SPECIAL CHARACTER SET.

    I complained and was told, oh that’s why we have the security number for (a unchanging six digit code), and I’m like, that’s basically 1 password with 18 character limit and 6 of the characters are definitely numbers.

    Not only that, 2FA is not available for logon, it just says “to authenticate certain types of Internet and Mobile Banking transactions”.

    I couldn’t believe it. Surprise, surprise, there are no minimum password security regulations in Australia…

        • primrosepathspeedrun@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          3 months ago

          OOPS we think this password is too long for you to remember, try again! and change it again in a month. your best buy account that we forced you create and are going to have a data breach on in about fifteen minutes is VERY IMPORTANT AND MUST BE SECURE

      • pixelscript@lemm.ee
        link
        fedilink
        English
        arrow-up
        6
        ·
        3 months ago

        I just reset my password with Southwest Airlines today. They had both the stupid 16 character limit and the stupid list of permitted special characters. But they also had the perplexing criterion that the first character of the password specifically couldn’t be one of those permitted special characters.

        Literally why.

          • pixelscript@lemm.ee
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 months ago

            I’m not saying it was a soft rule where the form refused to validate my input. It was an actual, fully-described rule in the bulleted list among the other rules. For whatever reason they specifically went out of their way to enforce it. And I cannot fathom why they would.

            • subignition@fedia.io
              link
              fedilink
              arrow-up
              1
              ·
              3 months ago

              I understood what you meant, it doesn’t change my answer though

              The back-end environment could have at least a few ways to screw things up if, for example, they were passing the password thru a shell script to hash it and had poor sanitization of the input

              !, #, and $ can be particular troublemakers at the start of a string, there’s probably more I’m not aware of too.

  • grue@lemmy.world
    link
    fedilink
    English
    arrow-up
    26
    arrow-down
    2
    ·
    edit-2
    3 months ago

    “correct horse battery staple” is for your password manager password. The regular passwords for services should be random character gibberish.

    Edit: to be clear, though, I’m not excusing their failure to allow >16 characters of gibberish.

  • Treczoks@lemmy.world
    link
    fedilink
    arrow-up
    23
    ·
    3 months ago

    Eons ago, I got an account for using a software on an IBM mainframe. Keep in mind that the machine used masks with fixed-width text fields on the terminal (TN3270, IIRC), even for the login mask. Being security cautious, the first thing I did after login was to change my password. The “change password” mask allowed for passwords of up to 12 characters, which I used freely. I logged out, got back to the login mask - which only allowed for an eight character password…

  • testfactor@lemmy.world
    link
    fedilink
    arrow-up
    21
    ·
    3 months ago

    Tell me about it. USAA has a password policy of “between 8 and 12 characters.”

    Like, that’s not even secure under old understandings of secure. A max of 12 should be, like, an actual offense with sanctions attached if they get hacked at some point. Especially for a financial institution. Ridiculous.

    Definitely used a one-off password for that one…

    • silkroadtraveler@lemmy.today
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 months ago

      Wow that’s true, what a crock.

      USAA strikes me as the most Wonder bread Texas Aw Shucks company that smiles to your face while outsourcing as much as possible (and stabbing you in the back in the process). Case in point. USAA only allows TOTP through Symantec’s proprietary app. I’m moving everything away from them except for auto insurance (which will likely go away at some point too as they’re not really that valuable for that anymore either).

    • Zidane@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      3 months ago

      I have to change my USAA password every few months because I forget about the 12 character restriction…

    • wreckedcarzz@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      Huh? I have had a USAA account for many years and my current password is far beyond 12 characters. I use both the website and the app…

      • testfactor@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        3 months ago

        Weird. I had to make up a new one cause all my normal passwords were too long.

        Several people on here have had the same issue it seems, and Google agrees thats their limit is 12.

        Not sure how you got around it. Maybe you’re using a USAA reseller or something? You sure that your password’s more than 12 characters?

        • wreckedcarzz@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          3 months ago

          Nope, direct account with USAA. I wonder if the way the user/pass is entered into the field, that it doesn’t trip the check for length? I don’t manually copy/paste, and also use autofill for initial setup/changing credentials. I’ve seen it before on other websites but it usually truncates on the login auth and yells at me.

          I just tried it, actually - sonofabitch. It (the change password flow) took the password via pw mgr, (apparently) truncated it, accepted it; this was a while ago but I remember the process. Just now, the login flow takes my username, password, truncates it (50+ chars, 13, or 12, doesn’t matter), accepts it. 11 chars throws an ‘incorrect login’ message, so I don’t have a borked account. At no point has it ever complained about password length. Jesus christ.

          • testfactor@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            3 months ago

            Absolutely beautiful. What a company, lol.

            The real beauty of it is that I can’t fathom the logic. Unless they’re storing the passwords as plaintext, it’s not like it can be a storage issue. The hashes will be a constant size. I guess it takes longer to hash bigger inputs, but like, that difference should be unnoticeable until thousands of characters.

            Did the engineer who made it truly not fathom that people might have passwords longer than 12 characters? That’s the kind of mid-90s logic that makes me genuinely worry that the passwords aren’t hashed on the backend, or are just MD5’d or something…

            Makes absolutely no sense at all.

  • CafecitoHippo@lemm.ee
    link
    fedilink
    English
    arrow-up
    19
    ·
    3 months ago

    My current employer has the dumbest restrictions for passwords to our core system. It is a large regional bank. Our core system must have a password that is either 7 or 8 characters long (nothing shorter or longer). It cannot have any vowels or special characters. It cannot have any capital letters. It cannot have two numbers in a row.