-
It seems like req for passwords go in direction of them getting longer and longer. I have problems to remember them sometimes. I friend suggest just to double my exsisting password, IE
: Lemon12 to Lemon12Lemon12. Is this good pratice or is there a problem with this method ?
-
That might be a temporary workaround. Better use a password manager which can generate good passwords (upper and lower-case letters, numbers and special characters). Each login/service with its own unique password.
-
I second this: Instead of memorizing passwords, remember one for your password manager and use it to handle long, random, passwords for you. These days, there are 2 or maybe 3 passwords, I actually know – all the rest I haven't even seen. They are long gibberish not intended for human use.
For passwords which you absolutely cannot have in a password safe for some reason, you may consider using pass-phrases, instead. -
The issue with password managers is taking away direct custody of the secret. One approach is to first generate a random string, then write it down in a notebook that's small enough to put into a safe or other secure place. You can generate random strings of printable ASCII with a command-line program called 'jot'.
The fewer passwords you need to memorize, the easier it is to make them random (because the keystrokes become part of muscle memory and you don't even think about it). -
For passwords which you absolutely cannot have in a password safe for some reason, you may consider using pass-phrases, instead.
-
The issue with password managers is taking away direct custody of the secret. One approach is to first generate a random string, then write it down in a notebook that's small enough to put into a safe or other secure place.
That's a non-issue. For example, KeePassXC can export the database as CSV. Import that into a spreadsheet, print the passwords, and put the stack of paper into your safe.The fewer passwords you need to memorize, the easier it is to make them random (because the keystrokes become part of muscle memory and you don't even think about it).
Does that work for 30+ logins/accounts (each one with its own password)? MFA? TOTP? Passkeys? -
I use KeePassXC because there are multiple front ends available of which I use two, suited to different devices. I like the fact I am not using anyone else's storage. This also requires a fit for purpose backup strategy.
It contains about 300 unique passwords, passkeys and TOTP strings. I know other people have more. The critical fact is that every one is unique, and that is the most important reason for having a password manager. Complexity of passwords then looks after itself by virtue of the manager's functions.
For my part I need remember only two pass strings or phrases, and my family needs only one because I created a separate encrypted file containing those critical access passthings, meaning also it is stored in different cities. I can kark it in peace. -
There is no move towards longer passwords. There is a move towards eliminating things, that never were secure passwords in the first place. Though I bet doing this by just increasing the length requirement will have the same counterproductive effect as requiring particular character groups had.
For passphrases you actually have to memorize, use Diceware (the original English list). Under no circumstances deviate from how it is described. In particular: don’t cherry pick words you like or dislike, don’t skip the requirement to have a separator between words, don’t use general-purpose random generators. There are some word categories you may skip, but make sure you consider them as entire categories and skip consistently as if they never were on the list. Not because your brain suddenly disliked one word. You may use a separator other than space.
But as noted by others, in general you should not remember secrets where this is not strictly needed. Use password managers and let them generate random, 20-character passwords consisting of A-Za-z0-9.
-
WINDOWS: Please enter your new password.
USER: cabbage
WINDOWS: Sorry, the password must be more than 8 characters.
USER: boiled cabbage
WINDOWS: Sorry, the password must contain 1 numerical character.
USER: 1 boiled cabbage
WINDOWS: Sorry, the password cannot have blank spaces.
USER: 50bloodyboiledcabbages
WINDOWS: Sorry, the password must contain at least one upper case character.
USER: 50BLOODYboiledcabbages
WINDOWS: Sorry, the password cannot use more than one upper case character consecutively.
USER: 50BloodyBoiledCabbagesShovedUpYourAssIfYouDon’tGiveMeAccessNow!
WINDOWS: Sorry, the password cannot contain punctuation.
USER: ReallyPissedOff50BloodyBoiledCabbagesShovedUpYourAssIfYouDontGiveMeAccessNow
WINDOWS: Sorry, that password is already in use. -
But what is a passwword?
-
What themadhippy did show is exactly the kind of password requirements that arose from ignorance, and from people with no proper training and exprtise creating or managing security systems.(1) I wished that was a scourge of the past, but unfortunately it is not.
Can you imagine in 2025 we still have major services having… an upper password length limit? Which makes you wonder, if their databases are still storing the passwords.But what is a passwword?
A harder to guess pasword, of course!
(1) And I can look at a much younger self at this point.
-
Can you imagine in 2025 we still have major services having… an upper password length limit?
Worse, some allow any length of entry but internally truncate, leaving you with a fantasy of greater security. This is very unhelpful if you choose a pass phrase rather than a random string, because ~3 words is not a proper pass phrase whereas 15 random characters is a decent one within such a constraint.
I know of one bank here that does this, or was as late as last year. -
WINDOWS: Please enter your new password.
USER: cabbage
WINDOWS: Sorry, the password must be more than 8 characters.
USER: boiled cabbage
...
https://neal.fun/password-game/ -
Can you imagine in 2025 we still have major services having… an upper password length limit?
Worse, some allow any length of entry but internally truncate, leaving you with a fantasy of greater security. This is very unhelpful if you choose a pass phrase rather than a random string, because ~3 words is not a proper pass phrase whereas 15 random characters is a decent one within such a constraint.
I know of one bank here that does this, or was as late as last year.
And less than 20 years ago this was standard on Unix-y systems; I was horrified to see that on our university machines, silently truncating to 8 characters. At that point, everyone already recommended longer passwords.
Truncating or otherwise modifying the password should be considered a criminal offense; an act similar to actual hacking into the system. It is totally unacceptable by any sensible logic, and nearly impossible to believe some serious organizations could be doing it in 2025. It was nearly unbelievable already in 2005. -
It seems like req for passwords go in direction of them getting longer and longer. I have problems to remember them sometimes. I friend suggest just to double my exsisting password, IE
: Lemon12 to Lemon12Lemon12. Is this good pratice or is there a problem with this method ?
No, doubling your existing password (e.g., Lemon12 -> Lemon12Lemon12) does not significantly improve its security. Such passwords can be cracked within fractions of a second using dictionary-based brute force attacks. For strong passwords, it's better to use long random combinations of characters - ideally at least 16 symbols or more.
Something like this: jMf_8q1%vKoE_o-5E[[Hx@Nu34_9277Z;4>AkN6F
A major problem is reusing the same password across different sites: entering it on one site exposes it to others. Therefore, passwords must be unique per service. Since remembering many long random passwords is hard, the best approach is to generate strong 20-30 character passwords and store them securely in a password manager.
-
WINDOWS: Please enter your new password.
USER: cabbage
WINDOWS: Sorry, the password must be more than 8 characters.
USER: boiled cabbage
WINDOWS: Sorry, the password must contain 1 numerical character.
USER: 1 boiled cabbage
WINDOWS: Sorry, the password cannot have blank spaces.
USER: 50bloodyboiledcabbages
WINDOWS: Sorry, the password must contain at least one upper case character.
USER: 50BLOODYboiledcabbages
WINDOWS: Sorry, the password cannot use more than one upper case character consecutively.
USER: 50BloodyBoiledCabbagesShovedUpYourAssIfYouDon’tGiveMeAccessNow!
WINDOWS: Sorry, the password cannot contain punctuation.
USER: ReallyPissedOff50BloodyBoiledCabbagesShovedUpYourAssIfYouDontGiveMeAccessNow
WINDOWS: Sorry, that password is already in use.
If you encounter such behavior with constant, sometimes absurd password requirements, it’s very likely someone wants you to create a password that’s easy for them to guess or crack, or just to capture passwords that you may also use on another resources. Its pretty real attack.
Most people tend to enter variations of their existing passwords across different services without much thought, which is a significant security mistake.
If you observe such system behavior, exercise extreme caution and under no circumstances enter passwords that resemble those you use on other services. Use a random string of characters instead. If the system still rejects it, this is a serious indication that it may be compromised and attempting to capture your passwords - report this immediately to the administrator.
-
Truncating or otherwise modifying the password should be considered a criminal offense; an act similar to actual hacking into the system. It is totally unacceptable by any sensible logic, and nearly impossible to believe some serious organizations could be doing it in 2025. It was nearly unbelievable already in 2005.
I’d say it depends on the length permitted. Bcrypt limits input to 72 bytes. I can’t blame anybody for simply truncating at that length, instead of having special hashing and error reporting logic just for an extremely rare special case. A case that, if happens, indicates some nonsense at user’s side. So while 16 is indeed “a criminal offense,” to me it doesn’t apply to all limits.
With modification it’s even more nuanced. For pure ASCII passphrases the situation is clear. But what about people from East Asia or using Arabic as their primary script? Visually and semantically same inputs may have different representation, so normalization must be done. Unlike with Latin script users, where a related problem exists with diacritics, there is no argument about users’ ability to switch to pure ASCII set.⁂
The truncation and modification isn’t really a security problem either. It’s the problem of freedom and abusing position of power to restrict it. All the imposed limits are usually having no negative effect on security, as long as you bow your head and submit yourself to what the organization demands. The failure point is the user, who dares to question authority and make own choices. Understanding that line of thought is IMO crucial. Otherwise we’re just Sisyphus rolling the password length stone, character by character each year.
Of course all this password stuff may soon become obsolete. A better solution has been found to remove the danger of choice. Simply remove the choice altogether: force users to install an app and secure the platform against user interference. -
I’d say it depends on the length permitted. Bcrypt limits input to 72 bytes. I can’t blame anybody for simply truncating at that length, instead of having special hashing and error reporting logic just for an extremely rare special case.
What, it is 2025 and we don't have a way for a function to return an error code, or exception, or a way to propagate these errors to UI?
There can be numerous reasons why a crypto operation fails. E.g., it detects that the RNG ran out of entropy. Or any of the gazillion input parameters or configurations are illegal. Or, among all other inputs - the password is unusable for the algorithm. So we can detect that the password is too short, and we can detect it doesn't have the required special characters, but somehow we can't detect it's too long?
In my opinion there is no excuse for silently truncating. The computer has to be able to say "password is too long". That level of error checking is expected even from toy projects or games. -
I'll have to look at a password manager then. Just do not like the idea of saving my passwords in an unknown program, I have no idea what it will do with the passwords. Also putting all my eggs in one backet feels like..... But it seems its the way to go. Thanks
-
What, it is 2025 and we don't have a way for a function to return an error code, or exception, or a way to propagate these errors to UI? (…)
We do. You still need to detect it, handle it, produce, test, and maintain that UI and entire separate scenario, clearly explain the situation to the user, deal with users confused by the grapheme vs byte count, have the user re-fill the password field (it’s cleared on the error). Compare that to just taking first 72 bytes of the input, which does exactly the same in 99.999% of cases, and works in 100% of sane(1) cases.
While I do understand (and agree with) the opposition to truncation to absurdly short lengths, I don’t get the negative stance on truncation in general. It will be done anyway, because it has to be: during the KDF stage.I'll have to look at a password manager then. Just do not like the idea of saving my passwords in an unknown program, I have no idea what it will do with the passwords. Also putting all my eggs in one backet feels like..... But it seems its the way to go. Thanks
Don’t put it in a random program. Choose wisely, set a good master passphrase, do monthly backups on a separate medium. You also can have multiple password databases, so it’s not exactly all eggs in one basket.
Also mind that having it all written in a notebook is also “all eggs in one basket,” except the basket is plaintext. Or, worse, not writing them down, but instead keeping in your head. Which universally leads to choosing weak passwords or — even worse — reusing passwords (or their fragments) across services.
(1) Having an over 72 byte password is some serious misunderstanding on user’s end.
-
Also mind that having it all written in a notebook is also “all eggs in one basket,” except the basket is plaintext. Or, worse, not writing them down, but instead keeping in your head. Which universally leads to choosing weak passwords or — even worse — reusing passwords (or their fragments) across services.
you can store passwords in a text file, encrypting it with a good key, and such a database with passwords can be uploaded into a cloud storage and you have access to it from different machines(1) Having an over 72 byte password is some serious misunderstanding on user’s end.
Some time ago I tried to use 50-100 letters password, but this is very inconvenient - firstly, entering the password takes a decent amount of time, which is very annoying, secondly, some services do not like long passwords and cut them off as was said, which sometimes leads to problems, because the code that checks the password can cut it off with a different length than the code that saves the password - I have encountered this in the past.
-
You still need to detect it, handle it, produce, test, and maintain that UI and entire separate scenario, clearly explain the situation to the user, deal with users confused by the grapheme vs byte count, have the user re-fill the password field (it’s cleared on the error). Compare that to just taking first 72 bytes of the input, which does exactly the same in 99.999% of cases, and works in 100% of sane(1) cases.
The circumstance I raised was truncation to 15 or 16 characters, not 72. An alternative to the above would have been to write "Your password must be 8-15 characters and contain DNA of a pink galah". If they typed more, they had been warned. The problem was that the enforced brevity was not included in any advice but was discovered by experiment.
It appears that the institution I had in mind fixed its problem a few years ago, earlier than I thought. There was another which until less than a decade ago limited passwords to 6 alphanumerics, not case sensitive! Your 10 character customer code was the better part of security. For years they covered it by providing RSA tokens to business users, which at least enabled you to authorise up to $1M without ado. Some institutions moved slowly. -
you can store passwords in a text file, encrypting it with a good key, and such a database with passwords can be uploaded into a cloud storage and you have access to it from different machines
At which point you just created a password manager. Just much worse and suffering from the standard effects of reinventing the wheel.Some time ago I tried to use 50-100 letters password, but this is very inconvenient - firstly (…)
Zerothly, this is “some serious misunderstanding on user’s end.” Thanks for making yourself an example.The circumstance I raised was truncation to 15 or 16 characters, not 72. An alternative to the above would have been to write "Your password must be 8-15 characters and contain DNA of a pink galah". If they typed more, they had been warned. The problem was that the enforced brevity was not included in any advice but was discovered by experiment.
The 72 byte case have been explicitly separated multiple times from your example, and it’s a reply to Siwastaja’s statement. -
If you don't want to use a password manager and want to remember passwords
then you simply need to make up some rules you can use to create a password for any website.
This is just an example, come up with your own rules.
Start by coming up with a silly sentence you will always remember.
eg my cats like to shit on the carpet.
Turn that into a password by using the first letter of each word and changing to=2 and for=4 etc..
mcl2sotc
This becomes the first part of your password and you will use it a lot and it's easy to type because you
can say the sentence in your head as you type it.
Now you can add on the end something that relates to the service or website you are signing up to.
Do this in upper case. eg, for facebook you might do mcl2sotcFB
Or, if you want to hide the fact the password is for facebook, just in case someone sees it in plane text,
then you can scramble it a bit more. Like using the next letter in alphabetical order, so FB becomes GC
If the website forces you to keep changing your password every month you can optionally add the month/year on the end. This really isn't a good way to do it, but its up to you to come up with something more interesting.
mcl2sotcGC125 for jan 25, mcl2sotcGC225 feb 25 etc..
You can add a special character into the rules if you want. So websites that need one are happy.
Now you just have to remember the rules and you know the password for any service/website.
- Easy to create long passwords that don't use common words
- Easy to remember even when they are long.
- Different password for each website
- Has lowercase, uppercase and numbers. etc.
It's not a perfect system, but it's easy to remember because you have to remember the rules every time you use a password for any site. The rules stay fresh in your memory. Unlike trying to remember a random passwords you used on a website 10 years ago.