Hacker News Reader

Comment by lobsang | Hacker News Reader

Maybe I missed it, but I was surprised there was no mention of passwords.

Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.

The first have obvious consequences (people writing passwords down, choosing the same passwords, adding 1) leading to the second which have horrible / confusing UX (no I don't want to have my phone/random token generator on me any time I try to do something) and default to "passwords" anyway.

Please just let me choose a password of greater than X length containing or not containing any chachters I choose. That way I can actually remember it when I'm not using my phone/computer, in a foreign country, etc.

View on HN

> Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.

I suspect that rotating passwords was a good idea at the time. There was some pretty poor security practices several decades ago, like sending passwords as clear text, which took decades to resolve. There are also people like to share passwords like candies. I'm not talking about sharing passwords to a streaming service you subscribe to, I'm talking about sharing access to critical resources with colleagues within an organization. I mean, it's still pretty bad which is why I disagree with them dismissing educating end users. Sure, some stuff can be resolved via technical means. They gave examples of that. Yet the social problems are rarely solvable via technical means (e.g. password sharing).

  >I suspect that rotating passwords was a good idea at the time.

yes, when all password hashes were available to all users, and therefore had an expected bruteforce/expiration date.

It is just another evolutionary artifact from a developing technology complexed with messy humans.

Repeated truisms - especially in compsci, can be dangerous.

NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.

This is actually a good example of an opposite case of Chesterton’s Fence

https://fs.blog/chestertons-fence/

It's not crazy to want a system to be designed such that it tends to converge to a secure state over time. We still have expiration dates on ID and credit cards and https certificates.

The advantages just didn't outweigh the disadvantages in this scenario.

Apples to oranges.

Usernames are public now.

Back then, your username was public, and your password was assumed cracked/public, within a designated time-frame.

Your analogy would hold if when your cert expires, everyone gets to spoof it consequence free.

The cert can still be broken. The signatures are difficult, but not impossible, to break: it can and has been done with much older certificates, which means it will likely be doable to current certificates in a few years. In addition, certificate rotation allows for mandatory algorithm updates and certificate transparency logs. CT itself has exposed a few actors breaking the CA/B rules by backdating certificates with weaker encryption standards.

Certificate expiration, and cryptographic key rotation in general, works and is useful.

apple cider to apples

https://leahneukirchen.org/blog/archive/2019/10/ken-thompson...

[previous hn discussion]: https://news.ycombinator.com/item?id=21202905

> which means it will likely be doable to current certificates in a few years

It is extremely unlikely a modern certificate will be broken in the time horizon of a few years through a cryptography break.

All systems eventually fail, but i expect it will be several decades at the earliest before a modern certificate breaks from a crypto attack.

Keep in mind that md5 started to be warned against in 1996. It wasn't until 2012 that a malicious attack used md5's weakness. That is 16 years from warning to attack. At this stage we dont even know about any weaknesses about currently used crypto (except quantum stuff)

Rotating certificates is more about guarding against incorrectly issued and compromised certificates.

Many modern crypto can be broken by nonce reuse.

Rotating certificates guard against bad PRNG and birthday paradox

I disagree. I don't think rotating certificates would help against birthday attacks or bad prng.

Tbh, i have no idea which part you are attacking with the birthday attack in this specific context. It doesn't seem particularly relavent.

(At the risk of saying something stupid) - i was under the impression RSA did not use nonces, so i don't see how that is relavent for an rsa cert.

For an ecdsa cert, nonce reuse is pretty catastrophic. I fail to see how short lived certs help since the old certs don't magically disappear, they still exist and can be used in attacks even after being rotated.

Certs should be checked against a CRL and CT for revocation, and expired certs should never be accepted, for this reason among others.

CT isn't used for revocation. CRLs aren't really a thing in practise. Refusing to accept expired certs is important for other reasons but won't save you from a reused ECDSA nonce.

If properly generated even the smallest RSA key sizes used in practice are still safe from birthday collisions.

But there have been several high-profile cases of bad RNGs generating multiple certs with RSA keys that had common factors. I think if you were put at risk by such a broken RNG, frequently re-generating your certs would tend to make things worse, not better.

Don't be nice, or do it thrice - hash input twice.

Crypto breaks are a concern for sure, but typically the more short-term concern is server compromise. Cert revocation is not reliably checked by all clients, and sites may not even know to revoke it.

So it's essential that if/when a bad guy pops a single server that they don't get a secret that allows them to conduct further attacks against the site for some indefinite period into the future.

Expiration dates on passwords is probably a good idea, except that it encourages bad habits from the end user. It encouraged bad habits since the expiration period was typically very short. For example: I don't have much of an issue with the 1 year period at one workplace, but I do have an issue with the 3 month period at another work place. The other issue is that people have to manage many passwords. Heck, I worked at one place where each employee was supposed to access multiple systems and have different passwords on each system. (Never mind all of the passwords they have to manage outside of the workplace.)

Contrast that to the other examples you provided. All of them are typically valid for several years. In two of the cases, people are managing a limited number of pieces of plastic.

You had 6 systems to log into, each with different requirements put on password. You are not supposed to share the password between system. Each system forces you to change the password in different schedule. And IT acts angry when you, predictably, forget password.

It did not converged to secure state, it necessary converged to everyone creating some predictable password system.

> NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.

Actually NIST provide a detailed rationale for their advice [1]. Attackers very much are attacking the entropy space (credential stuffing with cracked passwords is the #1 technique used in breaches). But password change and complexity rules are pointless precisely because they don’t increase the entropy of the passwords. From NIST:

> As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

[1]: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

> yes, when all password hashes were available to all users, and therefore had an expected bruteforce/expiration date.

Pretty much anyone I've spoken to candidly about rotating passwords has said that they use a basic change to derive the next password from the old. For example, incrementing a number and/or a letter. If that was as common a practise as I suspect, then rotating passwords doesn't add much security. It just meanstthat hackers had to go through a few common manipulation strategies after breaking the hash.

This is actually the third-order effect of itself, by itself.

Require frequent passwords, humans cheat, boom: your brute-force space just went from 1024 bits to 14, assuming you can onboard a red-team plant far enough to get the template for the default passwords.

If I know _bigcorp_ gives defaulted credentials in the format of [First Initial + Middle Initial + month_day] then not only can I piggyback a trivially-created IT/support ticket, I can also just guess that in 60, 90, 120 days, your credentials are the same, but the month_day - even if not correct, the search space is reduced by magnitudes.

Much of the advice around passwords comes from time-sharing systems and predates the internet.

Rules like "don't write passwords down," "don't show them on the screen", and "change them every N days" all make a lot more sense if you're managing a bank branch open-plan office with hardwired terminals.

It's funny, writing passwords down is excellent advice on today's Internet.

Physical security is easy, who's gonna see inside your purse? How often does that get stolen? Phones and laptops are high-value targets for thieves, and if they're online there could be a vuln. Paper doesn't have RCE.

(That said, I use KeePass, because it's nice to have it synced and encrypted. These days only my KeePass password is written down.)

I was going to say such advice does have its limits. Then I remembered something: even though my current credit card does have a chip, the design suggests that it is primarily intended as a record of a "user id" and "password" (e.g. large easy to read numbers, rather than the embossed numbers intended to make impressions upon carbon copy forms that typically became impossible to read with wear).

Not exactly. Some transactions are cryptographically authenticated. "The algorithm" looks at those bits. Transactions with proper chips authentication are less likely to be flagged as fraud

Also the embossed numbers are not that common in countries outside the US. For quite a while the numbers themselves are also disappearing from the front. (If you even use the physical card rather than your phone)

I remember being mind-blown on my first trip to the US when a taxi driver took my card and literally carbon copied it manually (with a pencil and carbon copy booklet) on the spot.

I had been using my credit card for at least a decade (Europe) and it never ever occured to me that the embossed letters had any function other than aesthetic.

And the cheques... jaw drop

That is how they used to work though. I’m old enough to remember imprinters, which literally used the embossed numbers to create a carbon copy: https://en.wikipedia.org/wiki/Credit_card_imprinter

I had a food delivery guy use one in the US 2012/2013. It was like seeing a native tribe perform their traditional dance. It still blows my mind that chip + "signature" is a thing in the US. What good is a random indiscernible scribble on a tiny resistive touch screen as far as proving anything?

It's quite illegal to fake signatures so it acts as a deterrent. I can't think of anything else...

I could be wrong but I'm pretty sure it is also illegal to steal someone's credit card and use it. If you have already done that, I don't think the idea of scribbling illegally is going to warn anyone off. Chip+PIN is objectively far more secure. People used debit cards with swipe+PIN for decades just fine and chip+PIN is used in many other countries without an issue. It is just silly to keep using signature and acting like it does absolutely anything at all.

That was how things worked back in the 80s and 90s, online or chip systems were in place 20 years ago in Europe

TBH where you see this kind of thing (mandatory periodic password rotation every month or two) being recommended, it's people not keeping up with even regulators view of good security practice.

Both NIST in the US (https://pages.nist.gov/800-63-FAQ/) and NCSC in the UK (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) have quite decent guidance that doesn't have that kind of requirement.

Well, my experience working in the industry is that almost no company uses good security practices or goes beyond some outdated checklists - a huge number wants to rotate passwords, disallow/require special characters, lock out users after X attempts, or disallow users to choose a password they used previously (never understood that one).

I think the number of orgs that follow best practices from NIST etc is pretty low.

It's not necessarily the organization's fault. In several companies that I've worked for (including government contractors) we are required to implement "certifications" of one kind or another to handle certain kinds of data, or to get some insurance, or to win some contract.

There's nothing inherently wrong with that, but many of these require dubious "checkbox security" procedures and practices.

Unfortunately, there's no point in arguing with an insurance company or a contract or a certification organization, certainly not when you're "just" the engineer, IT guy, or end user.

There's also little point in arguing with your boss about it either. "Hey boss, this security requirement is pointless because of technical reason X and Y." Boss: "We have to do it to get the million dollar contract. Besides, more security is better, right? What's the problem?"

I’ve had several companies, including cyber insurers, ask for specific password expiry policies and when I’ve gone back to them explaining that we don’t expire passwords and referencing the NCSC and NIST advice all of them have accepted that without any arguments.

As you say, these are largely box ticking exercises but you don’t have to accept the limited options they give you as long as you can justify your position

And to add to this, it can sometimes be helpful to reply to every wrongheaded security request with "I am not going to decrease the security of my users.". You can use before or after, but once you've explained why a request is not permissible, you can use this line instead of repeatedly explaining.

>lock out users after X attempts

Legitimate users usually aren't going to fail more than a couple times. If someone (or something) is repeatedly failing, lock that shit down so a sysadmin can take a look at leisure.

>disallow users to choose a password they used previously (never understood that one)

It's so potentially compromised passwords from before don't come back into cycle now.

I fail all the time. Oops, forgot to change my keyboard layout back or 'is it flamingmonkey1, 2, or 3 this time?' (because I have to rotate it every N months and clearly I'm not going to keep generating new passwords that I have to remember, unless the security people really explain why, which they never do), or 'oops, capslock was on', or 'does this password prompt require special characters (is it flamingmonkey1!?) or does it ban them? (or worst of all 'is whatever validates passwords just broken mysteriously and I have to reset my password to fix it?')

There's so many reasons I get passwords wrong. (it doesn't help that work has 4 systems that all use different passwords, all with different requirements).

If you locked me out (without me being able to easily unlock myself), I would immediately consider this an even-more-hostile relationship than normal and would immediately respond in kind.

> Legitimate users usually aren't going to fail more than a couple times.

Have your users authenticate to the wifi with a certificate that expires after 18 months, and you'll find users will reboot a dozen times or so, racking up authentication failures each time, before they call IT support.

>disallow users to choose a password they used previously

I think Epic Game Store hit me with that one the other day. Had to add a 1 to the end.

A common pattern for me is that I create an account at home, and make a new secure password.

Then one day I log in a work but don't have the password on me so I reset it.

Then I try and login again at home, don't have the password from work, so try and reset it back to the password I have at home.

> disallow users to choose a password they used previously (never understood that one)

That’s because you never responded to an incident when user changed their compromised password because they were forced to only to change it back next day because “it’s too hard to remember a new one”.

That’s easy to prevent:

Disallow the use of breached passwords - whenever a password change occurs check against e.g haveibeenpwned. No need to remember past passwords (which is another security risk btw if you ever get breached it will leak all passwords the user ever had).

I’ve been preaching this message for many years now. For example, since password generators basically make keys that can’t be remembered, this has led to the advent of password managers, all protected by a single password, so your single point of failure is now just ONE password, the consequences of which would be that an attacker would have access to all of your passwords.

The n-tries lockout rule is much more effective anyway, as it breaks the brute-force attack vector in most cases. I am not a cybersecurity expert, so perhaps there are cases where high-complexity, long passwords may make a difference.

Not to mention MFA makes most of this moot anyway.

Most of us can't remember more than one password. This means that if one site is compromised, then the attacker now has access to multiple sites. A password manager mitigates this issue.

Vary the password per site based on your own algorithm.

AKA, put the name of the site in the password :)

Not necessarily, but just a pattern that only you would likely remember.

You need a pattern that only you recognise/understand, not just remember. It takes only one leak of your password from service FooBar that looks like "f....b" to know what to try on other sites. Patterns easy to remember are mostly easy to understand.

With LLM that sort of approach can be attacked at scale

"MyPasswordIsSecureDespiteNotBeingComplexBecauseItIsLong_BobsForum" is great until Bob's Forum gets hacked and it turns out that they were storing your password in plain text and your password of "MyPasswordIsSecureDespiteNotBeingComplexBecauseItIsLong_Google" becomes easily guessed.

One way to mitigate such a problem is to use the hash of this text as the password, instead of using the text directly.

That algorithm becomes analogous to the password to your password manager.

People used to memorize the phone numbers of all important family members and close friends without much trouble. Anyone without a serious disability should have no trouble memorizing multiple passwords.

Sure, I do use password managers for random sites and services but I probably have at lower double digit amount of passwords memorized for the stuff that matters. Especially for stuff that I want to be able to access in an emergency when my phone/laptop gets stolen.

They did not. They had papers with all those numbers written down next to landline phones. They also had little notebooks they carried everywhere with them with those numbers written down. You could buy those little notebooks in any store and they fitted into a pocket.

Moreover, those numbers did not changed for years and years. Unlike passwords that change, like, every 3 months.

People used to memorize a few phone numbers, likely less than 10, and used notebooks made specifically for writing down phone numbers to keep track of the rest.

Phone numbers of the people you called the most (the 10 you memorized) were overwhelmingly likely to be local numbers, so you were only memorizing (3 number chunk) + (4 number chunk). Password rules are all over the place. Memorizing numbers, letters, whole words, the capitalization of those letters and words, and special characters, that are far longer than ye olde timey phone numbers, is orders of magnitude more difficult.

I have over 100 passwords in my password manager. They are all unique, so if any one is compromised, it is contained. My password manager is protected by strong 2FA, so someone would have to physically interact with my property to gain access. In the real world, there is no scenario where memorizing all your passwords is more secure.

Most people can surely remember beyond one password.

Not to mention they're like underpants, you can use the same one forwards, backwards, inside out, and inside out backwards.

Surely not more than 1 or 2

They can remember O(1) passwords, but they need O(n) passwords

> so your single point of failure is now just ONE password, the consequences of which would be that an attacker would have access to all of your passwords.

Most managers have 2FA, or an offline key, to prevent this issue, and encrypt your passwords at rest so that without that key (and the password) the database is useless.

> and encrypt your passwords at rest

I haven't turned off my desktop this year. How does encryption at rest help?

My password manager locks when I lock my screen. You can configure it to lock after some time.

The database is encrypted at rest.

Locking is not sufficient: it would need to overwrite the memory where passwords were decrypted to. With virtual memory, this becomes harder.

What's sufficient depends on your threat model.

Normal dude in a secure office? An auto-locking password manager would suffice.

Someone that should be concerned with passwords in-memory is someone who believes another has full physical access to their computer (and can, say, freeze RAM in nitrogen to extract passwords

My largest concern would be an adversary snatching my phone while my password manager was actively opened

Locking a password manager and your computer is certainly good enough in many cases. But gaining access to memory might not need the sophistication of using nitrogen (see eg https://en.m.wikipedia.org/wiki/DMA_attack).

But still not particularly hard. mmap has a MMAP_FIXED flag for this particular reason — overwrite the arena you’re decrypting to, and you should be set.

https://keepass.info/help/base/security.html#secmemprot

> On Unix-like systems, KeePass 2.x uses ChaCha20, because Mono does not provide any effective memory protection method.

So only Windows seems to use secure memory protection.

https://keepassxc.org/blog/2019-02-21-memory-security/

Ok, we seem to be moving the goalposts a bit.

My point is that you need to read up on it to ensure the implementation of memory handling for your password manager is really safe. As you demonstrate yourself, KeePass has different clients with different memory protection profiles which also depends on the system.

https://1passwordstatic.com/files/security/1password-white-p...

When your old hard drive turns up on ebay.

It's not safe to sell SSDs is it?

And even if it were, who would buy a used SSD with unknown durability gone?

If the data was always encrypted, then simply discarding the keys effectively means the drive is left filled with random data. Also, NVMe drives can be sent the sanitize command which can erase/overwrite the data across the entire physical drive rather than just what's mapped into the logical view. I believe there's SATA commands to perform similar actions.

> t's not safe to sell SSDs is it?

Bitlocker (or anything comparable) makes it safe or ATA Secure Erase if you can issue it (not usable for the system drive most of the times) and check it afterwards.

> And even if it were, who would buy a used SSD with unknown

it doesn't worth it for $30 drive, for the multi-TB ones it's quite common, especially for the ssrver grade ones (look for the PM1723/PM1733)

The one password and the app that uses it are more secure than most other applications. Lock out is just another term for DDoS if a bad actor knows usernames.

I love proton pass.

My bitwarden plugin locks out after a few minutes of inactivity. New installations are protected by totp. So one has to physically be at one of my devices few minutes after I leave even if they have a password. This reduces the attack source to a few people that I have to trust anyway. Also I can lock / logout manually if situation suggests. Or not log in at all and instead type the password from my phone screen.

I understand the conceptual risk of storing everything behind a single “door”. That’s not ideal. But in practice, circumstances force you to create passwords, expose passwords, reset passwords, so you cannot remember them all. You either write them down (where? how secure?) or resort to having only a few “that you usually use”.

Password managers solve the “where? how secure?” part. They don’t solve security, they help you to not do stupid things under pressure.

I was going to say passwords too ... but now I think passkeys would be a better candidate for dumbest ideas. For the average user, I expect they will cause no end of confusion.

That’s just recency bias.

Password policies are a joke since you use 5 websites and they will have 5 policies.

1. Bank etc will not allow special characters, because that's a "hacking attempt". So Firefox's password generator, for example, won't work. The user works around this by typing in suckmyDICK123!! and his password still never gets hacked because there usually isn't enough bruteforce throughput even with 1000 proxies or you'll just get your account locked forever once someone attempts to log into it 5 times and those 1000 IPs only get between 0.5-3 tries each with today's snakeoil appliances on the network. There's also the fact that most people already know that "bots will try your passwords at superhuman rate" by now. Then there's also the fact that not even one of these password policies stops users from choosing bad passwords. This is simply a case of "responsible" people trying and wasting tons of times to solve reality. These people who claim to know better than you have not even thought this out and have definitely not thought about much at all.

2. For everything that isn't your one or two sensitive things, like the bank, you want to use the same password. For example the 80 games you played for one minute that obnoxiously require making an account (for the bullshit non-game aspects of the game such as in game trading items). Most have custom GUIs too and you can't paste into them. You could use a password manager for these but why bother. You just use the same pass for all of them.

Dear user with password “password11111111111” logging in from a random computer with two password stealers active, from a foreign country, and not willing to use MFA, incident response team will thank you and prepare a warm welcome when you are back to office.

Honestly, this comment shows, that user education does not work.

Minimum length is dumb too because people just append 1 until it fits

I would love to see most drop-in/bolt-on authentication packages (such as DotNet’s Identity system) to adopt “bitwise complexity” as the only rule: not based on length or content, only the mathematical complexity of the bits used. KeePass uses this as an estimate of password “goodness”, and it’s altered my entire view of how appropriate any one password can be.

IIRC the key point there is that it's contextual to whatever generation method scheme you used--or at least what method you told it was used--and it assumes the attacker knows the generation scheme.

So "arugula" will score is very badly in the context of a passphrase of English words, but scores better as a (supposedly) random assortment of lowercase letters, etc.

I'm told that at work we're not allowed to have the same character appear three or more times consecutively in a password (I have never tried).

But when someone tries to attack such a password, as long as whatever the user devised isn't represented by an entry in the attack dictionary, the attack strategy falls back to brute force, at which point a repetition scheme is irrelevant to attack time. Granted, if I were creating a repetitive password to meet a length requirement without high mental load, I'd repeat a more interesting part over and over, not a single character.

Sure. But most people add “111111” or “123456” to the end. That’s why it’s on top of every password list.

If cracking techniques catch the concatenation of those as suffixes to short undefined things, which I think many people would do at minimum, that would be worrisome indeed.

Undisclosed minimum length is particularly egregious.

It's very frustrating when you've got a secure system and you spend a few minutes thinking up a great, memorable, secure password; then realize that it's too few (or worse, too many!) characters.

Even worse when the length requirements are incompatible with your password generation tool.

on the other hand, to gave us the password game, so there's that.

https://neal.fun/password-game/

> That way I can actually remember it when I'm not using my phone/computer, in a foreign country, etc.

I'd be very wary of logging into accounts on any computer/phone other than my own.

Based on the type of this rant - all security focused with little thought about usability of systems they're talking about - the author would probably be one of those people that mandate password rotation every week with minimum of 18 characters to "design systems safely by defatult". Oh, and prevent keyboards from working because they can infect computers via USB or something.

(Yes, I'm commenting on the wierd idea about not allowing processes to run without asking - we're now learning from mobile OSes that this isn't practically feasible to build a universally useful OS that drove most of computer growth in the last 30 years).

I don't get how it took until present day for randomly-generated asymmetric keys to become somewhat commonly used on the Web etc in the form of "passkeys" (confusing name btw). Password rotation and other rules never worked. Some sites still require a capital letter, number, and symbol, as if 99% of people aren't going to transform "cheese" -> "Cheese1!".

> people writing passwords down

Which is better, a strong password written down, or better yet stored a secured password manager, or a weak password committed to memory?

As usual, XKCD has something to say about it: https://xkcd.com/936/

Reply on news.ycombinator.com