EEVblog® Electronics Community Forum
Products => Computers => Security => Topic started by: RobNorthen on August 08, 2025, 02:18:18 pm
-
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.
[attach=1]
-
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 (https://en.wikipedia.org/wiki/Diceware) (the original English list (https://theworld.com/~reinhold/diceware.html)). 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/
-
https://neal.fun/password-game/
I got to this
ecstaticI!94mayshellVoVII75pfw
before I said "fuck it!".
-
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.
-
The 72 byte case have been explicitly separated multiple times from your example, and it’s a reply to Siwastaja’s statement.
I still think that input validation for setting a password should be mandatory. Truncating a "too long" one, or extending a "too short" one with e.g. symbol '0', are incorrect ways to deal with user being stupid. Requirements for password must be known and checked; there is no excuse for this.
-
Is this good pratice or is there a problem with this method ?
It's terrible. Easily guessable combinations of permutations of passwords are a risk (and crooks know the tricks!)
If you have trouble remembering passwords (and you should because you shouldn't be recycling passwords), then use a password manager like Bitwarden. Or, if you prefer a low-tech solution, a physical password book you keep at home. That way, you only have to remember one strong master password (or passphrase).
Don't keep them in insecure places on your computer, like a text document or Excel workbook.
-
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.
There was an airline whose web site would truncate your password to either 4 or 6 characters because that was the size of a PIN :palm:. I was going to add that it's the one where when you send in a service request they ignore it and then send you a survey asking you to give them five stars for service, but that's about half the airline industry.
-
Don't keep them in insecure places on your computer, like a text document or Excel workbook.
You mean you don't think this would be secure?
File: c:\Users\Me\My Documents\password.txt
Contents: password
-
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.
There was an airline whose web site would truncate your password to either 4 or 6 characters because that was the size of a PIN :palm:. I was going to add that it's the one where when you send in a service request they ignore it and then send you a survey asking you to give them five stars for service, but that's about half the airline industry.
Related pet peeve: people and companies who can't understand the difference between password and Personal Identification NUMBER.
Specifically, the use for a PIN has been as an extra check (additionally to security from physically having something), and in system that can seriously rate-limit false attempts, and do things like lock out the physical thing with too many false attempts. For that, even 4 digits (10000 counts) suffice.
-
Related pet peeve: people and companies who can't understand the difference between password and Personal Identification NUMBER.
Specifically, the use for a PIN has been as an extra check (additionally to security from physically having something), and in system that can seriously rate-limit false attempts, and do things like lock out the physical thing with too many false attempts. For that, even 4 digits (10000 counts) suffice.
We may extend this even further. Many institutions use “secret values” as passwords. In their naïve understanding, the threshold for “secret” is: I can’t guess the value by just knowing person’s name, so neither could “the bad guy.” 🤦
In Poland this is commonly the PESEL number. An identification number each citizen has. Not only it’s revealed to dozens entities while signing any major agreement or a support list, but in many instances it’s a public information available in official databases due to a person holding a high-ranking post in legal entities.
Could it get worse? Yes, never underestimate stupidity. In some instances organizations don’t use the full 10-digit(1) number. Instead, “to increase security” they choose a subset of digits. In the worst case this can be the first 6 digits, which happen to be calculated directly from the birth date. |O
(1) The full number contains 11 digits, but one digit has a linear relationship with the other 10. This doesn’t hold for invalid PESEL numbers, but those are too rare to have any real influence on security.
-
Hah, fixed! 8)
To the OP, the initial topic title can be edited. :)
-
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.
The problem with that is, some websites/services/networks require you to change the password, after a certain period. That's fine when I'm using it every day. I just increment a number, or letter, but it's a pain with I don't use it very often. I've given up with bothering to remember passwords I don't use regularly and need to be changed often. I just ask for it to be reset every time I long in, which involves receiving an email or text.
Heck there isn't strong evidence that forcing users to change passwords often increases security. It increases the risk of them doing silly things such as writing them down.
-
Heck there isn't strong evidence that forcing users to change passwords often increases security. It increases the risk of them doing silly things such as writing them down.
There is evidence for the contrary (https://arstechnica.com/information-technology/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/).
Last month NIST also published Digital Identity Guidelines (800/63B/4) (https://csrc.nist.gov/pubs/sp/800/63/b/4/final) (PDF (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b-4.pdf)) with advice regarding passwords. In 3.1.1.2. we see (emphasis added):Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
And that was already stated in previous version (https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final) (PDF (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf)) in 2017.
Even if mandatory password cycling had no negative impact on security, it would still be nonsense. In the best case, the idea is based on a threat model that became irrelevant a long time ago. More often it’s not based on any analysis at all. Instead it merely copies actions of others or relies on perceptions from literal ancient times.
-
Required password changing is like asbestos, it was known to be harmful for a very long time, yet stubbornly used regardless of increasing amount of unofficial and official statements that it should not be used.
-
Required password changing is like asbestos, it was known to be harmful for a very long time, yet stubbornly used regardless of increasing amount of unofficial and official statements that it should not be used.
Yeah, it's weird watching this in effect, I've been in security review meetings where every single participant agreed that it was a bad idea and then every single participant agreed that they had to do it.
In their defence, the reason was that if everyone else does it and they don't then it looks like they're not taking security seriously. Same reason why something innocuous like the USDA puts you through a security checkpoint when you go in, they can't be seen to be the only government agency that doesn't have security checkpoints.
-
Specifically, the use for a PIN has been as an extra check (additionally to security from physically having something), and in system that can seriously rate-limit false attempts, and do things like lock out the physical thing with too many false attempts. For that, even 4 digits (10000 counts) suffice.
It depends on how the PIN is applied, if it's to a secure device like an ATM then it's fine. If you can enter it online then it enables a PIN-spraying attack where you try the same PIN across all accounts, which doesn't trigger the lockout and gets you into one in every 10K accounts, in practice a bit more since PINs are quite unevenly distributed.
-
(…) in practice a bit more since PINs are quite unevenly distributed.
That “a bit more” is off by two orders of magnitude! ;) Details: All credit card PIN numbers in the World leaked (http://www.datagenetics.com/blog/september32012/index.html).
In 2010s I conducted a research on a forum I was administrating. The details are now lost in the past, but the bottom line was: 30 most popular passwords were used by 1/30 of the accounts.
-
Ah, thanks for doing the legwork. There was a conference paper on this some years ago at somewhere like Usenix Security but I quick google failed to locate it so I handwaved :-).
-
The problem with that is, some websites/services/networks require you to change the password, after a certain period. That's fine when I'm using it every day. I just increment a number, or letter, but it's a pain with I don't use it very often. I've given up with bothering to remember passwords I don't use regularly and need to be changed often. I just ask for it to be reset every time I long in, which involves receiving an email or text.
Heck there isn't strong evidence that forcing users to change passwords often increases security. It increases the risk of them doing silly things such as writing them down.
Agreed, there isn't a good solution for those sort of websites.
And yeah, I don't think it improves security at all.
-
Surely this comes down to what you believe is the risk.
If you use a pwd manager then somebody hacking into your PC, laptop, etc (or stealing it) could get all your passwords. Export in CSV addresses the backup policy issues but it doesn't help with security. And if security is not a worry then why not use e.g. the Chrome pwd manager? I am sure google has good security around that (due to the huge risk) and use that for everything, except financial sites whose pwds are stored in hard copy.
-
For the last five years it has been impossible to remember all passwords without password manager, or, if you want them to be secure, a flashdrive. All important passes I save on the flashdrive
-
The best solution I could come up with is to write my own simple password manager. I've not had time to actually do it, may never do, but at least it would be a bespoke system which makes it super unlikely any person or app running on my PC is going to steal the data from its data file.
There's a lot of people trying to break the encryption of common password manager data files or break into the running apps memory. There's so many users that the payoff of breaking it is huge. However virus and malware can only go after password managers they know exist.
One thing I'm not too sure about is how password managers actually populate password data into password entry boxes.
I'm assuming they don't just simulate keypress codes since any other app on the system could probably intercept that.
So writing your own password manager might not be as simple as it first seems. (encrypted DB + text output into the in-focus win control)
There potentially lots of obfuscation going on.
Then again, if you unknowingly have a dormant credential stealing virus on your PC perhaps you're already screwed even with common password managers. So maybe simulating key scan codes is fine as an entry method
-
AFAIK if your machine is compromised then you are screwed, because windows messages can always be intercepted.
In fact the messaging system which is used extensively within windows has been a major security headache over the decades.
Banks etc nowadays assume your machine is compromised (because most normal people are simply too stupid / careless, and many use p0rn etc websites i.e. they are pretty careless what they browse) so setting up new payees involves a phone call or SMS.
Google's Chrome pwd manager might actually be more secure, on a compromised machine, than a 3rd party manager, because Chrome might be injecting the data internally, and just faking the pwd asterisks or whatever.
-
One thing I'm not too sure about is how password managers actually populate password data into password entry boxes.
Typical solutions are:
- clipboard (often with a time limit, you do the copy & paste)
- auto-type (involving some optional simple scripting to cover special cases)
- browser-plugin
Some password managers can also pass SSH keys to an SSH agent, for example
-
The problem with that is, some websites/services/networks require you to change the password, after a certain period. That's fine when I'm using it every day. I just increment a number, or letter, but it's a pain with I don't use it very often. I've given up with bothering to remember passwords I don't use regularly and need to be changed often. I just ask for it to be reset every time I long in, which involves receiving an email or text.
yes, in practice these measures can significantly weaken security rather than strengthen it. Forcing regular password changes often leads users to adopt predictable patterns - such as appending a date or incrementing a number, simply to keep track of the changes. This makes the passwords easier to guess and undermines the very purpose of the policy.
Similarly, arbitrary restrictions on password composition (e.g., disallowing certain symbols, requiring a fixed mix of character types, or rejecting perfectly strong passphrases) can push users toward creating long but highly repetitive or formulaic passwords that satisfy the filter yet are far more vulnerable to attack. Worse, these policies often reject genuinely strong passwords for no good reason.
Such rules are often implemented by administrators who have a limited understanding of real-world security issues. I have repeatedly encountered situations where these policies and filters not only created unnecessary headaches for users but also introduced serious vulnerabilities. While to the uninformed they may appear as strict and reasonable measures, in practice they frequently weaken security and create a host of additional problems.
And you would be mistaken to think these issues are hypothetical. I have personally encountered attacks of this kind, where users were subtly steered into choosing easily guessable passwords under the pretext that their original choice failed to meet certain security criteria. Once the weaker password was entered, it was accepted without issue. This is a sophisticated attack method that combines elements of social engineering with a man-in-the-middle approach.
The use of such practices - frequent forced password changes combined with complexity rules - has a troubling parallel to the promotion of biometric authentication. Biometric systems are often marketed as a security enhancement, but in reality they make it easier for malicious actors to impersonate you once they gain access to your biometric data from government or corporate databases. By consenting to the use of biometrics for identity verification, you are in effect giving attackers a permanent "key" that cannot be changed.
What many people fail to realize is that biometrics are not about enhancing security - they are about making impersonation easier for those who manage to obtain your data, money or want to put you into slavery state. Consider this: facial recognition or fingerprint authentication offers no protection if you are coerced or physically restrained. In such a scenario, an attacker could effortlessly unlock every device and service tied to your biometric profile - face, fingerprint, etc. Moreover, stolen biometric data, unlike a password, cannot be reset, and can be traded or sold on illicit markets. So, almost any criminals can use it to impersonate you forever.
The underlying danger of imposing biometrics is that it enables criminals to act in your name, across multiple systems and organizations, without your consent and without your knowledge. Just as flawed password policies can push users into predictable, weak behaviors that aid attackers, biometric systems can provide a single, irrevocable point of failure - only this time, the "password" is something you cannot change.
-
Required password changing is like asbestos, it was known to be harmful for a very long time, yet stubbornly used regardless of increasing amount of unofficial and official statements that it should not be used.
I'm seeing it become less and less of a thing, which is good. I'd say almost all of my online services never require a routine password reset. There might be one or two that do, but I couldn't even tell you which ones they are.
-
Required password changing is like asbestos, it was known to be harmful for a very long time, yet stubbornly used regardless of increasing amount of unofficial and official statements that it should not be used.
I'm seeing it become less and less of a thing, which is good. I'd say almost all of my online services never require a routine password reset. There might be one or two that do, but I couldn't even tell you which ones they are.
Yes. Just like the dangers of asbestos being known and discussed in 1930's and widespread epidemic among workers dealt with starting from 1960's, resulted in the ban in civilized world in 1990's (60 years being well-known, 30 years being obvious disaster), it seems in 2020's we are finally getting rid of scheduled password changes. How long did that take? Quite similar to asbestos - in case of password changes, 50(?) years being understood as a bad practice, at least 20 years everyone agreeing it's kinda-sorta disaster which should be stopped immediately.
-
At which point you just created a password manager. Just much worse and suffering from the standard effects of reinventing the wheel.
Sure, technically that’s a primitive password manager. But I’d prefer such one over relying on someone else’s code and not knowing if there are backdoors or “convenient” key tricks hidden inside. Actually I'm using my own password manager written in C# at 2007 and I’m still using it today.
Zerothly, this is “some serious misunderstanding on user’s end.” Thanks for making yourself an example.
No misunderstanding here — I just pointed out the practical side. A 100-character password is great for entropy, but it’s far from convenient in daily use.
It was just an experiment. A 100-character password is obviously strong against brute force, and with certain mnemonic rules it’s not too difficult to memorize. However, in practice it turned out to be very inconvenient to type. I eventually reduced it to around 30–40 characters, mixing upper/lower-case letters, digits, and symbols.
Since a 8-character password can be brute-forced within hours (test results with open-source optimized code on GPU), I assume 20 characters can be considered strong, so 30–40 characters provides a reasonable safety margin against potential algorithmic weaknesses that could reduce brute-force costs.
However, this also depends on the resource — if it’s a non-critical service, a shorter password may be acceptable. The key point is to avoid reusing the same password across different services.