In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)

Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.

  • nelson@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    You think that’s infuriating? Imagine having an ISP that wants you to pick a password of max 8 characters.

    • Pika@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      11 days ago

      I’ll do you one better. The target redcard credit card doesn’t allow non-standard special chars, max I think it was 12 chars and gets pissy at using known SQL special chars. If it wasn’t for the fact it required a credit check prior to getting to that screen I would have ran so hard.

      What’s even more annoying is their password field says that it does support that, but if you try via the mobile app it errors out

          • feannag@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            Sure but that doesn’t change the lack of competition. For my address, I have two non wireless providers, and one of them is copper only and capped at 50 down. So not a lot of choice if an ISP is screwing you.

            • Possibly linux@lemmy.zip
              link
              fedilink
              English
              arrow-up
              0
              ·
              11 days ago

              That really sucks

              I feel like it is cases like that were community run infrastructure can really help. It provides decent service and puts pressure on the local ISP to do better.

  • dQw4w9WgXcQ@lemm.ee
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    For a system I worked on a few years ago I got the password requirement:

    • Only upper case letters A-Z, no letter or symbols.

    • Exactly 7 characters.

    I was also recommended to make it a single word to make it memorable.

  • obsidianfoxxy7870@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    YES, it pisses me off so much. Though I do kind see for some things having some upper limit of 256 for certain services. But I may be wrong in thinking that.

    For example I want a secure bank password but I only need it so long. Mainly because unlike my E2EE service if they are servered a warrant or hacked through another service all my data is there. Basically I can only do so much.

  • lennee@lemm.ee
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    11 days ago

    funniest experience that ive had is that i made a psn (playstation network) account with a 64 (iirc, might have been 32, dont remember) character password. That worked making the account on my PC on their website. Never was able to log into that account on my playstation tho and the error message was just some generic error. Support didnt know what was going on and i didnt either until it dawned on me. The password was too long for the console. Changed the whole thing to a shorter one and now it works everywhere. Used to work on their website, not in the app, not on console. Fun.

  • foggy@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    Okay so I agree with you that a longer password is better but this in no way indicates clear text password storage.

    • troed@fedia.io
      link
      fedilink
      arrow-up
      0
      ·
      11 days ago

      It does. If you hash the user passwords, which you should, the hash is always the same length and it’s thus irrelevant how many characters the user’s password consists of.

      Now, it’s not certain though, which wasn’t claimed either, because the front end developer might have other reasons for setting limits. The backend shouldn’t care though.

      • IphtashuFitz@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        It could be an older codebase that’s using an inline encryption algorithm as opposed to a hash. Using an encryption algorithm with a private key would result in varying length outputs.

        • troed@fedia.io
          link
          fedilink
          arrow-up
          0
          ·
          11 days ago

          That’s the same as “cleartext” for someone who works in security though, since that means anyone with the private key can decrypt the password.

      • x00z@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        The backend should care though. Even if strings can have an unlimited amount of characters, you don’t want to go and hash a gigabyte of data. In lower level languages you don’t have magic strings either so you might do something like char password[64].

        There’s many reasons to limit raw password length. Not many good ones to have it as small as 24 (or even 64) though.

        • troed@fedia.io
          link
          fedilink
          arrow-up
          0
          ·
          11 days ago

          I agree you might have threat actors looking to DoS your system if there’s a publicly exposed REST endpoint accepting gigabytes of data. That has nothing to do with the discussion on password hashing though.

          • x00z@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            The claim was that a limit on passwords implies plaintext storage. It doesn’t. There is no such thing as unlimited on computers.

            • Kissaki@feddit.orgOP
              link
              fedilink
              English
              arrow-up
              0
              ·
              edit-2
              11 days ago

              The claim was that a limit on passwords implies plaintext storage.

              quoting the post:

              Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or

              It was not a claim that it certainly is plaintext storage. It was claimed to be a possibility. AND provided an alternative explanation.

              Maybe you’re more confident than me in good practices and implementations across all services. But I’ve seen enough to know that’s not always the case. It’s good to be skeptical on anything related to security.

              • x00z@lemmy.world
                link
                fedilink
                English
                arrow-up
                0
                ·
                11 days ago

                but this in no way indicates clear text password storage.

                It does.

                No it doesn’t.

                • troed@fedia.io
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  11 days ago

                  It does.

                  /80’s hacker turned Software Engineer turned Cybersecurity professional

            • troed@fedia.io
              link
              fedilink
              arrow-up
              0
              ·
              11 days ago

              Don’t worry, I’m autistic myself and understand how difficult it can be to parse “it’s thus irrelevant how many characters the user’s password consists of” to mean something besides “all implementations must accept an unlimited amount of characters”.

              I do believe the point was understood by the general reader however.

                • grysbok@lemmy.sdf.org
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  11 days ago

                  Curiousity: Could you please explain what was awful about the comment you responded to?

                  For context, I’m also autistic.

          • CosmicTurtle0@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            Exactly. The tax on hashing the password can’t be ignored and if you’re doing this enough times it can kill a system. 24 characters is too low. I’d say 100 characters is enough for most use cases. 1024 if you’re feeling 1337.

            • troed@fedia.io
              link
              fedilink
              arrow-up
              0
              ·
              11 days ago

              Sure, but when we talk about the computation then the number of rounds is by far the more important factor compared to password length.

              The discussion is about whether 24 characters indicate cleartext though - not whether password lengths should be in the gigabytes.

        • hummingbird@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          11 days ago

          There is no good reason so send the passwors itself to the server. Send the hash and you will have a fixes length of data to send anyway.

          And even if insist in sending the password over the wire, there is no problem on the backend to handle longer passwords than that, so that no one will run into a limit in practice. We’re talking about bytes here, not even a kb.

          • Pika@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            you absolutely should not be hashing client side. You need to securely transmit the password to the server where it is hashed. You do not want clients knowing /how/ the password is salted/hashed. this lowers your security overall.

          • x00z@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            There’s some software that hashes the password clientside before sending it, sure. But it still should be hashed serverside too.

                • Sonotsugipaa@lemmy.dbzer0.com
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  edit-2
                  11 days ago

                  Plaintext password (693 chars):
                  “hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2”

                  Clientside SHA-512 hash (64 bytes):
                  7399ed78effda820b2187bc70f0549dd67f6846c595f944d198a1f1136cd0ab91119d6f208a34b4419e969b9ffb326d3786cecb90828f0ab36a5e3835558740c

                  — Client sends 64 bytes to the server —

                  Serverside SHA-512 hash (64 bytes):
                  25293199e10af10e8a20f4ab38abccd2cdccd762d8cba2ed4871a2aea8fe6d9ffcc54cfe1c9cbd03245bfd2f0ee1039f06083b7bcbefd91b7fcbba182d588983

                  At no point the server has to deal with the length of the plaintext

          • IphtashuFitz@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            Proper hashing of a password includes a salt that should be kept private. This means the password should definitely be passed to the server in plaintext. The server adds the salt to the password, then hashes it.

            This adds more protection should an attacker somehow manage to get access to your hashed passwords. Even if they identify the type of hashing mechanism used it will prevent the use of rainbow tables, dictionary attacks, etc. against the hashes.

            • troed@fedia.io
              link
              fedilink
              arrow-up
              0
              ·
              11 days ago

              While I’m not arguing for doing the crypto client side, the salt isn’t needed to be private - only unique.

              • IphtashuFitz@lemmy.world
                link
                fedilink
                English
                arrow-up
                0
                ·
                11 days ago

                It definitely needs to be private. If an attacker can obtain both the password hashes and the salt(s) (via the same database vulnerability for example) then they have everything they need to run offline attacks against the passwords.

                • troed@fedia.io
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  11 days ago

                  No, it most definitely does not need to be private. The idea with salt is to invalidate rainbow tables. If you’re “keeping it private” it’s just another password.

                  The salt and the password (or its version after key stretching) are concatenated and fed to a cryptographic hash function, and the output hash value is then stored with the salt in a database. The salt does not need to be encrypted, because knowing the salt would not help the attacker.

                  https://en.wikipedia.org/wiki/Salt_(cryptography)

                • mic_check_one_two@lemmy.dbzer0.com
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  11 days ago

                  The salt is specifically to invalidate pre-generated rainbow tables, and doesn’t need to be kept private. It only needs to be unique.

                  The attacker generates rainbow tables by running common passwords through known hashing algorithms. So I run “password1” through a bunch of different algorithms, and save the results of each. Notably, generating decently large rainbow tables takes a lot of time, processing power, and storage space. Because you don’t just use common passwords; You’re basically running a brute force/dictionary attack on your own computer’s hashing algorithm.

                  Now if a database is unsalted, I can search for matching results against my rainbow table. When I see a match, it tells me both which users had that password and which hashing algorithm they were using. So now I can narrow down my focus to only using that algorithm.

                  But if a database is salted, all of my pre-generated tables are useless. Even if someone used “password”, it won’t match my rainbow tables because the hash was actually fed “password{hash}” instead. And even if multiple users used “password”, each salt is unique, so I don’t see a bunch of repeated hashes (which would point to those accounts using the same password). I would now need to generate all new tables with the salts I stole in order for my rainbow tables to be usable again. And even then, I’d need to repeat that table generation for every user.

    • Zikeji@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      Is the maximum 24 characters because their database column is a VARCHAR(24)? That’s one of the first questions that I thought of. Sure, it doesn’t guarantee plaintext, but it’s a indicator that it may be stored plaintext, considering hashing doesn’t care about length. Or at the very least whoever has had eyes on this code doesn’t know shit about security, which makes me less confident in the product as a whole.

      The only reason I can think of to have a maximum would be to save on bandwidth and CPU cycles, and even then 24 characters is ridiculously stingy when the difference would be negligible.

      • Redjard@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        Cryptographic hash functions actually have fixed runtime too, to avoid timing-based attacks.
        So correct password implementations use the same storage and cpu-time regardless of the password.

        • Ziglin (it/they)@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 days ago

          I figured it was about the time spent transmitting. But the password should probably be hashed before sending as well as upon arrival at the server, correct?

      • x00z@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        bcrypt hashes only the first 72 bytes. 24 characters is the max amount of 4 byte UTF8 characters when using bcrypt. Which is stupid because UTF8 is variable, but still, it’s a possible explanation.

    • BestBouclettes@jlai.lu
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      What would be the other reason for a password length limit so low ? I could understand limiting to like 64 characters but 24 sounds low.

    • axh@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      I heard some banks encrypt single characters of the password separately (no idea how that would be safe) they often ask to provide random characters from the password instead of the entire password.

      My bank only accepts up to 20 characters. It doesn’t validate it… The login page simply ignores all characters beyond 20th. So I didn’t even know that it cut my password until I tried to log into the mobile app, which replaces the last character when you type more than 20… that was confusing 20 minutes when I didn’t know why I can’t log into my mobile app.

    • Kissaki@feddit.orgOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      Password hashes always have the same length.

      Why is there a limit at 24? It may be an arbitrary limit set, or it may be because they don’t store more.

  • baltakatei@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    11 days ago

    In my opinion, an acceptable password length should be L in ln(alphabetSize^L)/ln(2) = (B bits of entropy). For a Bech32 character set (since it excludes ambiguous characters), alphabetSize = 32. A good password should have been 96 and 256 bits of entropy, with 128 bits being my personal preference. This means L = (B)*ln(2)/ln(alphabetSize) = 128*ln(2)/ln(32) = 25.6 = 26 characters.

    That’s… pretty close to what OP said they were restricted to, so maybe the person who set the 24 character restriction used a similar methodology.

    By the way, here’s a Bash script for generating bech32 passwords of specified entropy.

  • tarsisurdi@lemmy.eco.br
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    11 days ago

    I once registered an account with a random ~25 characters long password (Keepass PM) for buying tickets on https://uhuu.com.br/

    The website allowed me to create the account just fine, but once I verified my e-mail, I couldn’t log into it due to there being a character limit ONLY IN THE LOGIN PASSWORD FIELD. Atrocious.

    EDIT: btw, the character limit was 12

      • scintilla@lemm.ee
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        I understand a cap of like 64 characters or something to keep storage space down for a company with millions of users. other than that it doesn’t make a ton of sense.

        • mic_check_one_two@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          11 days ago

          The cap should actually be due to the hashing algorithm. Every password should be the exact same length once it is salted and hashed, so the actual length of the password doesn’t make a difference in regards to database size. The hash will be a set length, so the storage requirements will be the same regardless. Hashing algorithms have a maximum input length. IIRC the most popular ones return a result of 64-255 characters, and cap at 128 characters for input; Even an input of just “a” would return a 64 character hash. But the salt is also counted in that limit. So if they’re using a 32 character salt, then the functional cap would be 96 characters.

          Low character caps are a huge red flag, because it means they’re likely not hashing your password at all. They’re just storing them in plaintext and capping the length to save storage space, which is the first mortal sin of password storage.

          • Redjard@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            10 days ago

            You can easily get the hash of whole files, there is no input size constraint with most hashing functions.
            Special password hashing implementations do have a limit to guarantee constant runtime, as there the algorithm always takes as long as the worst-case longest input. The standard modern password hashing function (bcrypt) only considers the first 72 characters for that reason, though that cutoff is arbitrary and could easily be increased, and in some implementations is. Having differences past the 72nd character makes passwords receive the same hash there, so you could arbitrarily change the password on every login until the page updates their hashes to a longer password hashing function, at which point the password used at next login after the change will be locked in.

        • Redjard@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          0
          ·
          11 days ago

          That is a huge red flag if ever given as a reason, you never store the password.
          You store a hash which is the same length regardless of the password.

          • scintilla@lemm.ee
            link
            fedilink
            English
            arrow-up
            0
            ·
            11 days ago

            Youre right lol. I forgot that hash lengths are different from the actually password length.

          • Cethin@lemmy.zip
            link
            fedilink
            English
            arrow-up
            0
            ·
            10 days ago

            Although at some point you’ll get collisions, but I don’t think that’s actually an issue. It still equally hard to guess a password from the hash, there will just be some solutions that are much longer than others.

    • FiniteLooper@lemm.ee
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      I’ve had this exact same thing happen.

      I’ve also had it happen where you have the two fields to verify the password is the same. One had a maxlength set in it, and the other didn’t. I was for sure entering the same password and I was so confused until I opened up the dev tools and inspected the inputs.

  • kibiz0r@midwest.social
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    Recently had a password that was acceptable for the account creation page on the website but too long for the login screen in the mobile app.

    Took me a while to figure out that pasting into that field was just quietly dropping characters.

    • nocturne@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      What is worse is when it does not quietly drop any characters and you have to keep resetting your password.

  • magic_lobster_party@fedia.io
    link
    fedilink
    arrow-up
    0
    ·
    11 days ago

    What’s more frustrating is when the password creation page is silently cutting off too long passwords and don’t inform you about it.

    • jj4211@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      Back in the day, long time ago, Unix would do that, and limit user silently to 8 characters.

      Which then wasn’t great, but a good password would be hard to break even at only 8 characters with equipment of the time.

      We would do a cracking test against the user passwords periodically and ding users who got cracked. Well one user was shocked because they thought their 16 character password was super secure and there’s no way we would crack it. So we cited her password and she was shocked she went through so much trouble only for the computer to throw away half her awesome password.

    • neilb@lemmy.ml
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      There’s a site I use that does that on the password reset page, but not when logging in. So when using a long password it’s as if the reset never works. Took me ages to figure out what was going wrong.

  • Kissaki@feddit.orgOP
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    I’ve had a case in the past where I reduced my password to the limit, but after account creation, I was not able to log in.

    Turns out they had an off-by-one issue, and a password with a length slightly below the limit worked fine.

    • fatalicus@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      Experienced a site some years ago that let me I put however long password I wanted (my default is 52 in my password manager), but turns out it only used the first 20 or so.

    • valkyre09@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      11 days ago

      I once got locked out of an HP printer because it chopped off the last few characters of a password. Only figured it out because somebody had made a comment online about password length

  • Annoyed_🦀 @lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    11 days ago

    24 is fine, not as bad as 12 and no special character. That’s honestly the worst one i’ve encounter.

    my bank app doesn’t allow copy paste so i can’t have anything that long and hard to type, and they tend to request password login when transferring money.