If you're logging in from a library computer, you don't want the hassle of putting your privkey file on it and wiping it later. (Or connecting a USB drive, which may be a security hazard for the library)
If you lose your computer, you still remember your password, but your only copy of your privkey may be lost. Losing hard drives is common for non-power users, because they don't do regular backups, and they often don't know that you can trivially recover files from, e.g. a laptop with a broken screen that won't boot.
And computerized cell phones are actively trying to convince those non-power users that files don't even exist, to protect their profits.
Now, public key cryptography is indeed promising, but you see something rather more sophisticated to deliver privacy and security and that's what WebAuthn is.
I'm not clear on the password part (I'm assuming it was a typo).
I have no idea why this wasn't immediately huge. You see the login button, you tap it, your existing fingerprint reader or whatever verifies you are still you, whoever that is, and you're logged in, done. Much more secure than people's crappy passwords, yet much easier to use even than the crappy passwords.
Key material rotation seems to be a sensible practice in general.
Not meaningfully. Let's take my Hacker News password and we'll imagine you happen to know (somehow) exactly what the format is, so then you start guessing.
And we'll imagine you can make 1 billion login attempts per second, which in fact I'd guess will make dang pretty unhappy 'cos the servers won't like that.
And maybe you get to do this on a billion computers, and for a billion seconds, again I'm thinking somebody would notice and stop you, but let's just say...
At the end of all that you've still got orders of magnitude less chance of guessing my password, for this web site correctly than a random ticket buyer has of winning the jackpot in a typical state or national lottery game. Get a new hobby.
I think people struggle with the numbers involved. Even astronomical numbers are too small, because astronomical numbers involve practical things, like how quickly light travels and maths does not need to be practical.
"There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers." - Richard Feynman
(26+10)⁶ = 2,176,782,336
1,450 minutes a day
2,176,782,336 / (1,450 * 60) = ~25,000 years
But let's say you want to do it anyway. There is no need to memorize or type the entire key; a site-specific private/public keypair can be derived from a memorized master password and the domain name (for uniqueness) via a KDF. The site never needs to see the master password, so in the event of a breach all your other logins remain secure, and there are no key files to synchronize, just a single password for access to all your accounts.
You do need to trust that the PC you're using to log in is secure, though, since it has access to the master password; I'm not sure how you would get around that without involving some other trusted piece of hardware, and if you have that you could just use it to access the site instead.
Number of 6-character alphanumeric passwords: (2*26+10)**6 == 56800235584
Number of seconds in a year: 60*60*24*365 == 31536000
Number of years to enumerate all 6-character alphanumeric passwords at one password a second:
>>> ((2*26+10)**6)/(60*60*24*365)
1801.1236549974633
Which a consumer of a service does not know. There's law now to force providers of services to announce leaks/breaches and there's haveibeenpwned; both are no guarantee.
Changing a password gives consumers a fresh start.
> Passwords do not age. They do not sour, spoil, or stale.
The "fresh start" does imply some sort of spoiling/ageing.
Rotating passwords (re-freshing) in the age of password managers is not that much work, for some critical accounts that may be a good thing.
I highly recommend it for people that are more computer savvy. For the digital illiterates OnePass may be more suitable.
PasswordSafe was designed by Bruce Schneier.
I'm the person that you should thank for that, I believe.
the Hive infograpgh (amongst others) always comes to mind; 18 characters long, upper, lower, numerical, special. estimate time to brute force 438tn years.
But that still doesn't mean forced regular password rotation makes you safer. Changing your password is in itself a relatively high risk activity. And the likelihood of your password leaking tends to be dependent on factors you control.
For instance, if you assume that a given service provider won't leak their password database (which is usually hashed in some way), you are being optimistic. You should always expect that this can happen and act accordingly when choosing, or preferably generating, a new password.
Do you mean if you reuse the same password(s)?
> But that still doesn't mean forced regular password rotation makes you safer.
Would you say that even for people who use a password mamager and generate their passwords?
What? If they're not breached then that invalidates the other two points anyway - unless you can find an authentication endpoint that doesn't rate limit. HTTP proxies are expensive and trying to brute force something that is on-server is not a common attack vector.
I know its nit-picking, but the title is incendiary and warrants that.
Big takeaways:
Longer passwords.
No hard requirement of symbols.
Passwords don't change unless its in breach notifications online
Regular scanning of breaches for hacked login/passwords or commonly used passwords
Whoever came up with the idea that passwords need to be regularly changed must be shot because no one has ever proved it makes any sense.
What it actually does is that people write passwords everywhere (papers, text files, etc), thus actually lowering their security.
- ssh did not exist or was not widely used. People used telnet, ftp, rlogin, etc. which put plaintext passwords on the wire.
- UNIX systems that used NIS distributed the password file to clients via a plaintext map which could be obtained by anyone with “ypcat passwd”. Many passwords were guessed in seconds using crack or John the ripper. Complex passwords would withstand those attacks for weeks or months with those tools using a single computer to reverse them.
- (I think) NTLM and CIFS authentication put password hashes over the wire. Various tools were available to reverse these as well. Once it was feasible to build rainbow tables, getting a password from a hash was a simple lookup.
- switched networks were not widely used making sniffing passwords or hashes from the wire much easier. Hubs would broadcast all traffic from all ports to the other ports on the hub. Coaxial Ethernet daisy chained many computers along the same physical wire. I think that “ring” networks (token ring, fddi) also passed all traffic by all nodes.
In those days, regular password changes were important because your password it it’s hash was regularly exposed.
I’d argue that today, any password you type where someone else may have a camera should be treated as though it has also been compromised. This means that if your password manager isn’t auto filling it, you should be using that password only with two factor authentication.
(edit: formatting, auto-carrot)
That seems like a good way to ensure people don’t use stupid passwords: public embarrassment.
a) Passwords should be easily rememberable. Pick four words are string them together (e.g. correcthorsebatterystaple). b) You must have a physical security key to authenticate - a Yubikey etc.
If those two factors are not enough, then forget working from home / mobile authentication - require people to arrive in-person and work in-person, with network restrictions on top of the two-factor authentication.
If two-factor authentication isn't enough, and IP address restrictions aren't of help to enforce know-your-user when they show up in person, then I swear, God help you. At that point, you're no longer practicing security, you're practicing paranoia.
That is exactly what I thought was the case too until I recently entered the code Google Authenticator gave me although my mobile was not connected to the internet. And it worked.
TOTP is supposed to work without a network connection.
This assumes you'll know if passwords were exposed in a breach. Some breaches go undetected.
If you use unique passwords for everything and a leak goes undetected, the damage is contained to just that one site/service.
cherry picking quotes to nitpick is only effective if you address the full quote rather than cherry picking a point of a cherry picked quote
The beauty of public key authentication is that there's nothing to breach on one side.
But how confidentally we know this. Hence, people periodically change password. Or am I missing something?
Password databases can and should be storing that data using proper hashing functions like Argon or bcrypt. Those are designed to be slow, so brute-forcing them even offline and in parallel becomes time-consuming. This increases the time between when a breach happens and when those passwords become useful to attackers. This gives the service more opportunity to detect the breach and force users to reset their passwords.
If attackers somehow obtain actual passwords before then, then the login system should be using risk-based authentication, where it throws additional challenges if the user appears to be logging in from a completely unexpected IP address or client.
Bit of an ideal conditions assumption.
If security isn’t breached then you by definition don’t have a security issue
You might never know if operator lost your pw.
Meaning, if your password is 10 years old it's subject to any leaks or security events during that long time frame. If it's 3 months old, anything that could have happened to it must have happened in the last 3 months which is much better than 10 years.
At every company I've ever worked that required password rotation, everyone just incremented a digit, usually at the end.
I also hate the completely arbitrary rules on length (I mean, why do some sites have a maximum length?). Some require uppercase and lowercase as well as digits and certain special characters and what special characters are allowed is inconsistent and completely arbitrary.
We need to focus on how much entropy [1] a password has without arbitrary rules. 20 lowercase letters is going to be better than a 7 letter dictionary word with one letter capitalized and a number of symbol on the end. In fact pretty much every password 8 characters of length should be considered cracked. 10 should probably be the absolute minimum.
What Should You Do?
There’s a simple checklist of improvements you can make to keep your passwords forever secret:
If you aren’t already, start using a password manager.
Use the password manager to generate strong, unique passwords for every account.
Review old accounts that contain personal, proprietary, or financial information and update their passwords using the password manager.
Never share personal facts, like your pet’s name, when required. Instead, replace a real fact with random text that you store in your password manager for later access.
Enable two-factor authentication wherever available.
Other trends I've seen:
Passwordless auth tying into WebAuthN. If a site can tie into a method secured by the OS, all the better. I'm not sure the uptake, but have seen some presentations/comments about it being a far superior UX. Also, seen some startups built (and raising $$$) around just this.
Known, trusted bigcos like Facebook (ya, I know, but they are trusted by lots of non tech folks) and Google. This has some upsides because they can secure accounts really well, and also keep on top of new security reqs like MFA. But there're plenty of HN stories about being locked out of these IdPs, so this may be a bit of a scary delegation for some.
Passwordless auth tied to email. This is great for low value, infrequently used accounts because often 'send me creds via email' is the default path anyway, usually via 'forgot password' flows.
https://keepassxc.org/blog/2020-08-15-keepassxc-password-hea...
This is because they create another problem when anyone you talk to will say they have their password and just increment a number for every password change. That way they’re not having to remember a whole new password every few months. So there’s never much of a change in anyones password during these rotations.
- abcde1 - abcde2 - abcde3 - …
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Source: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
The policies are the problem and the industry has recognized it so they’ve moved away from those recommendations.
However, if you use a password manager, and have access to it, I think forcing key rotation on a short schedule actually increases security. The downside of course being that most people don't use a password manager, and most people use the same relatively unsecure password for everything.
Every company (all 3 of them) I have worked at within the last 10 years, the IAM team has already implimented, or was working on implimenting a system that removed regular rotation, special chars and number requirements, and relied on three things: Length, a dictionary check at the time of pass creation, and routine dictionary attacks against the credential store. This started 10 years ago, for someone to make the same claims now, is not a shock.
Please note that if you are unable to impliment such an IAM system, especially the inability to dictionary check the credentials against known lists (seclists' github is great for this), then length plus regular rotation is still the recommendation
Password rotation every 75 days. No dictionary check. No check against known breached passwords. No real reasonable rules against insecure passwords (like ac_Paul2022 is valid 'secure' password).
Additional massive "spyware" on corporate devices in the name of security.
I don't care about security since being 'on system'. I don't do anything private on these devices. So I couldn't care less about what mothership does with their spy-/securityware on said machine.
I couldn't care less about the security. I cared when I could do something about security. When I had control about the security on the device.
But why should I nowadays care.
It takes a long time for industry-standard to catch up to actual practice.
Password($MONTH)($YEAR)!
Or, PasswordJanuary2022!
It easily increments to deal with stupid arbitrary rotations, passes most tests, has the small/large/number/symbol requirements.
And it's sooooooo hackable its not funny. Hell, 2 jobs ago, I ran this precisely because of 60d rotation garbage.
We all knew that the controls were bad, but we had to use them
Increment a digit at the end of your password and stick the current digit on a post-it below your monitor, like everyone does. Then get on with real work.
In a business when the password reset request rate gets high, it usually gets easier and easier to reset passwords. I worked with a govt system as a contractor supporting a subcontractor. They had such annoying password rotations and a DOUBLE password system (users didn't understand, but one was for a VPN sort of thing and the next was for the app) that coupled with frequent rotations of both passwords and very slow account provisioning meant reset requests were crazy high.
But the good part? You could literally call the number, provide a username, and then they'd read you the temporary password right then. They'd actually outsourced password reset because the volume was so high they couldn't support it with their staff!
A) Hi, I need a password reset. B) Sure, what's the username C) It's XXXX D) Do you need password1 or password2 reset? E) I'm not sure? F) No problem. Use AAAA for the first password and BBBB for the second.
It was basically the system routing around damage so folks could get their jobs done.
So why do I have an Azure password that I have to change every few months? I always set it to a randomly generated string; certainly not anything in a dictionary.
It's just that it was a strident recommendation for 10 years prior to that, perhaps because many systems didn't support long passphrases but it was drummed into enough heads that it is now "conventional wisdom" especially in many business and government "enterprise" shops.
Even my latest employer, an academic institution with security folks who know better, still forces a passphrase change every other year.
So optimistic. We just got dinged on this for SOC2 and I had to send over the so800-83b document that states as much.
The solution is for a standard to emerge that incorporates rotation and (optionally random) password generation used across sites. No more fucking "Login with Google".
Of course, by remember, I mean put in a .txt file somewhere.
Both of your suggests disregards the user's experience and security is only ever as good as your user's willingness to use it.
But updating a password is itself an attack surface. More so than merely using it to log in.
It's one of the times where an attacker may be tricking you into giving it to them, either by a fake page or app dialog, or in concert with maybe they have a way to receive the verification email or text.
Also it's a less frequent operation, meaning it's easier to fake. You are more likely to notice any tiny discrepency and detect a fake in the way your normal login screen looks than some account management screen.
Basically updating a password is a riskier action than the normal daily use of the same password.
And that alone is it's own even stronger argument for avoiding doing it unnecessarily.
She only knew because I'm on the recovery password list and as soon I received the email from Google asked her to confirm.
In practice, this new rule contradicts almost every InfoSec stance out there, but all government agencies must comply with this new rule by the end of the year, so expect lots of conversations and changes.
[1] https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0... Approachable summary at https://www.bastionzero.com/blog/i-read-the-federal-governme...
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed.
Shameless plug - I'm the cofounder of Clerk and we handle passwords in a sane way out-of-the-box: https://clerk.dev/features/passwords
And as others pointed out, breaches aren't always known or disclosed. Is it too late if you change your password 6 months after it's compromised? Not sure - maybe people sit on their exploits sometimes, or wait for a better buyer, or sell secrets in small batches.
All that said, I've never changed a password when it was newer than 5 years old, and only do it for crucial services, but if I were a bigger target, I might do it more.
Assume the passwords for all of your users are public. Doesn't matter how it happened. How are your users protected?
The moment that people go down this road of thought everything gets a lot better.
1. How do you restore accounts that may have been taken over?
2. How do you detect logins that look like normal behavior vs those that don't?
3. Is a password alone enough to get them in?
If you address those 3 things everything gets A LOT easier for you and your users.
When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.
My oldest online account - btw it is a brokerage account at one of the big brokerage houses, where a great deal of my cash and investments sit - has not asked me to change the password in close to 25 years, which I find quite funny.
To be fair to these companies, the reason they do passwords so terribly is because of such poor guidance and standards in the past. Even now NIST has SP 800-132 for guidance on generating a cryptographic key from a password for storage applications, which is different and often confused with guidance on storing passwords (which they don’t give advice for). There they say to use PBKDF. Also, compliance standards such as PCI don’t allow for modern storage like Argon2, so at best companies use something like bcrypt.
For my own personal use, I just use a password manager + randomly generated passwords, but it seems corporations are so damn slow to pick up on these obviously beneficial things that they choose clearly antiquated standards instead.
3password
4password
...
>=]
These can go undetected. Imagine
1. Hacker dumps database with your username & password in it 2. Brute-forces the database offline 3. Logs in as you / Sells it to 3rd party that logs in as you
A lot of time can pass between these steps. Changing your password is a mitigation against this scenario.
If you steal the WebAuthn database from my toy implementation, now, or tomorrow or ten years in the past, it makes no difference because it doesn't have any secrets in it, so, you don't learn anything useful. "Man, if I was this web site, which I'm not, now I could validate that the authentication was successful".
In such schemes the only thing similar to a "secret" is the Private Key, which exists only briefly temporarily inside my Security Key or other authenticator when it is doing its thing.
I find sites that ignore my opinion on password security annoying. Some sites I just don't use because of their password policy.
Best practices get better over time. Maybe two years ago that password was stored as an MD5 hash, and that hash was getting leaked to log data. Bank.com has since fixed that problem, but you don't get the benefit unless you change your password.
Assuming NTLM hashes you can currently crack almost 100 billion hashes per second on a single AWS p3.16xlarge that costs $25/hour to run (https://www.thesecurityfactory.be/password-cracking-speed/)
I.e. you’d need 10 million hours of these machines to try every combination possible, with an average time to crack of 5 million hours. I.e. a total cost of $125 million, although I bet you could negotiate a pretty good AWS discount and/ or build the servers yourself and optimize them for cracking, so let’s call it around $50 million to crack a truly random 12-ASCII character password today.
Assuming Moore’s law improvements and improvements in energy costs/ efficiency and we can reasonably assume this cost could roughly halve every 18 months, to under $1 million in a decade. That’s not a lot of money to a nation state actor, so if you’re in a position where you seriously worry about active attacks against you specifically, perhaps using passwords that are longer than 12 characters is worthwhile.
1. The password must be difficult to the point of impossible for a computer to guess.
2. The password must be memorable enough that a person can create it once and then remember it a month later.
If you don't satisfy requirement #1 then it will be hacked with a GPU farm. If you don't satisfy requirement #2 then the users will undermine your security in a multitude of ways. Almost no corporate password policy attempts to address or even facilitate option #2. They don't even mention it! Many corporate password policies are actively hostile to option #2, requiring a bunch of stuff that's hard for people to remember but only reduce the search space for the computer farms attacking your leaked password database.
I like to use phrases made of things that sound like words, but aren't in the dictionary. Make them themed to be memorable. I call them Jabberwocky passwords. Were it not in famous poem a good password would be "mimsy were the Borogroves".
[0]: Something like https://github.com/fblz/PassFilter or https://github.com/rlabolle/hibppwdflt
Sure, it's technically possible to decipher the algorithm[0] I use to generate new passwords, but that's not what I'm protecting against. If someone is trying to attack a specific person, there are much more effective ways[1].
[0]: For example, if my password for HN is "1y2c3o4m5b!$", you could sit down and figure out my reddit password.
[1]: https://gizmodo.com/how-i-lost-my-50-000-twitter-username-15...
If you're worried a password will leak, how frequently should you rotate it to maintain security? e.g. Even rotating yearly still seems a chore if you do it for websites you don't frequently visit (such as sites you made 1 order from).
The "add YYMMDD" or whatever is a way of working around a policy which automatically enforces a more frequent rotation than you want.
Companies RMA, sell off, donate, and/or dispose of older drives, RAID caches, computers, workstations - are you 100% sure everything was DBANed properly without any data still lurking in bad sectors? All it takes is one snoopy fellow dumpster diving, or going through the garage-saled hardware of your former IT guy who made backups, finding some hardcoded credentials on an unencrypted or poorly encrypted drive - or other similar act of stupidity - to potentially leverage mistakes made years ago into active network access.
As annoying as I find password rotation, I get it.
I would say, strong password is slowly becoming a myth due to organizations failing understand what it is before creating a policy surrounding it.
While they are at it mandate some standards of customer service if your business exceeds $1M in gross revenue (must have a "get human" button and the call hold time shall not exceed 15 minutes).
I know that sounds like a fantasy utopia, but I remember a time in the 70s when there was a serious push for consumer advocacy in the US.
It has take literally over a decade to relax the requirement for password rotation from 3mo to 1yr for employee accounts of companies that process CC payments, despite industry knowledge and formal studies saying that frequent password rotation was detrimental and useless.
Instead of defining the process, state the outcome you want and set penalties on failing to meet the outcome.
E.g. "don't have password leaks, or it will cost $1k per account paid directly to the account holder" (or your percent of gross, split among leaked accounts). Let companies implement those controls however they wish, as long as they are achieving the outcome and penalties are actually being applied.
I agree that failures need to have significant penalties, otherwise companies will decide that the penalty costs less than the prevention (which is true today) and minimize their investment in security.
I feel like this is somewhat true for self-fulfilling prophecy reasons; these same organizations don’t always disclose every compromise or leak of their systems, and don’t always force a password reset when it happens because it would reveal they’ve been hacked. I’m certain I have multiple online accounts at organizations that have suffered minor, major, and ransomware level breaches.
- The password is weak
- It is ever reused
- Anyone else has access to it
- You use it on a device you don't control
- You use it on a device which might be running malware and can intercept it
- It was stored insecurely
While sharing passwords is never a good idea, sometimes it is necessary. For example, I am the treasurer of a non-profit organization, an elected position that rotates every two years. We have a savings account at a credit union that for a variety of reasons requires online access by multiple individuals who change over time. The only way to keep this even a little secure over time is to require a password change every time someone drops off the authorized access list.
There could also be software licensing issues that lead to multiple users sharing a login for software, same thing applies.
1) You don't know whether the service or site employs best practices e.g. throttling. (Although you might be able to test that yourself if you're tech savvy.) So you may have to assume the worst, and there goes Point 1.
2) You can't be sure they will report a breach if it occurs, or that the password will ever show up in e.g. haveibeenpwned. So there goes Point 3.
Point 2, you do have control over.
Of course modern dictionary algorithms will still look for characters that are commonly used as substitutes for letters ($ = s, # = h, ! = 1 etc.) so really you just want your password to be random, long and unique.
Does actually. I still require some of the password "rotation" schemes folks would use when we were forced to change them monthly (not a typo, sadly):
1qaz2wsx -> 2wsx3edc -> 3edc4rfv...
Pass1word -> Pass2word -> Pass3word...
If you're generating your passwords randomly (using a password manager) it actually reduces security because it reduces the set of acceptable passwords.
The U.S. Fed Gov has been implementing MFA with smart cards since 2001. While there are pockets of ineptitude and resistance, the vast majority of government employees and contractors use a hard token second factor.
Security is a property of a system, so analyzing a particular password policy outside of the given context (mandatory hard token MFA) is nonsense.
Yeah, that's because those stances are not based in fact, but repeated bad ideas left over from the 70s and 80s.
Except other national bodies like NCSC [1], and long-standing academic research e.g. [2, 3], that is!
1. https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
2. https://dl.acm.org/doi/abs/10.1145/1866307.1866328
3. https://link.springer.com/article/10.1007/s10623-015-0071-9
> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
The only thing prolonging your account at that point is the service's rate-limiting, assuming a naive "enter this password in the login field, try it, repeat."
On a few sites I've actually used old student ID #'s - easy to type and reasonably long, with the exception of one, all are 6+ characters.
Far too short.
For many systems, users can memorize 6 digits easily.
The reality is, whatever your password reset flow is is enough. If you can reset your password with a 6 digit number via text, then that is maximum needed for actual password as well in most cases.
Leaking a password on your side is an unknown unknown, so password rotation is not a bad practice on its own for a security conscious person: It limits a leak in time.
Mandatory password rotation is a whole different kettle of fish, as it pushes users to lower password quality. Infosec policy was required to balance 2 conflicting needs, and the past has thougt us we balanced wrong.
I'd say no... some compromises are "2 step"... Ie. someone accidentally was logging the passwords in plaintext for a few months to some logs system (compromise 1)... and then years later some attacker breaks into the logs system (compromise 2).
Or you accidentally typed a password into a terminal and it got stored in your .bash_history... and then months later you accidentally make your dotfiles github repo public, including your .bash_history containing your password...
Also, some thieves may compromise your account but not do much evil with it (and remain undetected). And then many months later they sell your account to someone else who does do evil with it.
Writing passwords down isn't the worst thing. If you can't convince someone to use a password manager like 1Password, getting them to use a physical notebook of unique and strong passwords is actually the next best thing, because (combined with 2FA) it protects them against the most relevant threat models for most people (phishing and password stuffing).
At home maybe, but in other environments this can be pretty bad.
We either need password managers or we need to do away with passwords entirely.
You don't know and that your brokerage did not ask you - it can mean anything, they might have had a breach already but they kept it secret.
Idea about rotation of passwords is that you assume that your password 'was leaked/cracked' and you don't know about it and have no way knowing it.
That's really not the user's responsibility at that point. It's up to the service to store passwords securely (i.e., use proper password hashing functions) and monitor login behavior to throw up extra challenges if things look suspicious.
Password rotation is a high-cost measure placed on the user that has little (even negative) benefit, especially when there are more effective alternatives the service is better-positioned to implement. Users cannot twist themselves into knots to make up for shitty service-side design decisions.
Nobody complained. I think it's a better solution than making the user come up with their own strong password with annoying special character rules when you can just generate one for them.
The interesting challenge was making it work well with all password managers though which often have mind-numbingly dumb heuristics about what could possibly be a password field. It's worth a blog post.
A good analogy for banks risk mitigation is like putting up a guard rail in front of a cliff. It's up to the user how high the rail gets set. Like daily limits, notifications, initial passwords, 2fa etc.
For the most part, banks and brokers want to reduce the friction of events.
I needed to have less secure passwords under new security regime. More open ports. More services being exposed to the net, more code with potential bugs running on my machine and so on.
If you want to take over any of the big firms I would probably target a tool like Tanium [0] being employed by a lot of these corporations.
Last time I checked still based on python 2.7 (EOL 2020-01-01).
This was in my case installed as well as Flash with the pretense of security. I was a bit underwhelmed.
I actually told CIO about py27. And about it already being EOL. They did not know that (neither the tool using it, nor it being EOL). And they actually did not care. And told me not to care about it, as the mix of different tools would provide absolut security.
I have to say, I agree! Once an endpoint security tool gets installed on my laptop and my administrator privileges have been revoked, I would definitely feel like the security of the unit was out of my hands. IMHO, this makes the organization almost entirely reliant on software and policies (which likely go unread) for security.
My belief is that this will result in an overall less secure posture for the organization as a whole. As this poster points out, his password is now less secure because whatever tool judges its strength is behind the curve. Other people may be more prone to open suspicious email under the impression that the endpoint security tool will take care of it. And so on.
To get there though, we need better email hiding (Apple’s Hide My Email is great for this, you can get unlimited randomly-generated @icloud.com addresss that forward to your real one) and for sites to not actually need your real name or personal information.
If done right, if randosite.com gets all emails and (even if plain-text) passwords leaked, it wouldn’t matter because only Apple can tie the email to my account, and the password would only be good on that site anyway.
If a website actually needs my real address and name for billing information, that’s another matter maybe, but even then who really cares? The existence of my home address and name doesn’t much matter if they can’t tie it to any other online identities. My address is in the phone book too… it doesn’t really give anybody new information.
Since seeing this I became even more of a cynic. If they want to scare us - at least they should do it intelligently.
But yes, that is the hope. I did push back somewhat on a local city system that went down this rediculous path (blocked password managers, hand type password only, crazy complexity requirements and rotation for a low risk system - think looking up a water bill).
Upper case, lower case, digit, special character, does not match any previous password, changeable monthly without having to write it down…
Which means that an attacker now knows that moving "only numeric" to the beginning of their attack sequence may be a viable strategy. Whereas if the rule did not specify, the attack would not be able to make assumptions about the character set.
Even if you rotated your password frequently, there would still be a large window of compromise. Password rotation only helps with very strange attack scenarios, and passwords themselves aren't really good enough for anything where security actually matters.
I would personally push away from passwords on the whole at this point. SSO is probably more secure for most users. Plenty of websites only support username+password auth, and given how bad most passwords are... I might even go so far as to suggest that username+TOTP is instantly more secure than that, especially with proper rate limiting as you should have anyways. (Yes, I know TOTP is "supposed" to only be a second factor.)
WebAuthn takes this to the next level and promises a future where you can use a strong single factor to log in, without any opportunity for phishing or credential compromise... but most implementations I've seen still require a fallback password mechanism. There are understandable reasons for this right now, but it is unfortunate.
There original threat model for forced password rotation was supposedly based on hash cracking time. This is a stupid threat model; the guy from NIST who wrote it back in the 80s admitted it was based on no research but was added arbitrarily because it sounded good at the time.
Explaining that it is not industry standard anymore takes time and if they want to take time of their employees using our system to deal with that, I am not wasting our company time to make them right.
A: It's a good idea! B: In theory, yes. In practice, no. A: I'm only talking theory.
Great. The rest of us are talking about practice.
Anything below 5 in distance gets rejected, try again, please.
While you get to change password you make 2 boxes with current and new of course and do your comparisons on it, just to explain you still keep passwords hashed.
password02february
password03march
...
You can specify pretty high difficulty with argon2id etc. Ie, shoot for a one second runtime with a very high memory requirement (you can go to GB range even).
So I'm not sure all is always necessarily lost
The only reason it's even tolerable risk to walk around out in the wide random world with a debit or credit card on your person all day every day, is because somewhere else you have the means to disable it and declare it lost.
This is like storing the keys to your car conveniently right on your car.
Most people don't use password managers, and some companies block their usage. Now add a requirement of a "secure" password.
This issue for master passwords is a bit harder, yes.
1. What characters count as special? Does "special" mean non-alphanumeric? If so, just say that, don't say "special".
2. Among those, which ones will be accepted by your password system? Is \ acceptable? Will ™ be accepted? What about emoji (which evidently HN comment input doesn't seem to accept)?
Most password entry prompts do not answer either of these questions, so you have to either guess or just use ! or # and move on with your life.
P@55w0rd!
Is an awful password, yet meets many security policies
P@ssword2, P@ssword3, P@ssword4 etc
Also meet them, and rotate just fine.
Meanwhile
dadbffc67f798e8e0b7441fb995aeabe
Is perfectly fine, but often is not allowed
Nor is "correct horse battery staple". For wanting symbols, so many password systems really hate spaces.
Don't worry, the first 10 letters are randomly generated a-z or a-z0-9.
Area code was likely all the same, maybe 2-3 tops, and associated both with the following exchange and geography, and used extensively.
Exchange, also likely all the same, maybe 6 at most, and again likely associated with geography.
The average person doesn't even have ten good friends, much less a need to memorize dozens of phone numbers. They would buy address books / contact books to write down dozens of numbers, not memorize numbers they very rarely use.
Weak passwords can be fine, provided rate limiting is extremely aggressive. You can adjust this based on access e.g. your admin account might be locked under stricter heuristics like a single attempted login outside your geographic region (Live mail does this to me sometimes). In this case the user might even have the correct password, but if something else doesn't add up then you can block.
https://www.kcbd.com/2021/10/12/new-10-digit-dialing-procedu...
Note the date on this: Oct 2021!
> Starting on Monday, October 25, 2021, Texans with phone numbers in the 254, 361, 409, 806, 830, 915 and 940 area codes must dial 10-digits (area code + telephone number) for all local calls.
I don't think anyone, even the original responder, views it as an actual password we should all use.
Most of the time, local networked IPs all start with the same values for the first 3 octets (maybe 2 if VLAN but then usually only one digit diff). The same was true for most people's local phone number memorized registry. Those of us old enough, we only had to dial 5 digits using (70s) the last number of the prefix before eventually moving to 7 digits to include the full prefix (80s). The world suddenly changed when we had to dial the entire area code as well (90s).
Which will result in two things:
1. LOTS of calls to IT from forgotten passwords
2. People writing their passwords down on sticky notes.