I still don’t get why someone using a password manager would make up passwords themselves instead of randomly generating long and strong passwords...
The way they implemented this is nice, but seems a bit pointless to me.
The way they implemented this is nice, but seems a bit pointless to me.
Eventually decided to give them all stronger unique passwords (because why not) and it was a pretty easy process because the password manager could show me all the sites with duplicate passwords.
I've imported my passwords from Firefox's password manager to a dedicated one a few years back, and I've been generating new passwords ever since.
There's still dozens of occurrences of the one-password-for-all-services I've used previously, because nobody will go through the hassle of changing passwords in hundreds of online services. I do change it whenever the autofill appears too short to be randomly generated, but I still didn't get rid of all of them.
With that said, I'm not using 1Password and I've already checked my old password in Troy's service to make sure it wasn't in a breach.
If we'd use something like certificate auth it'd be less of an issue, but currently password managers are a horrible trend because they encourage using your password for a service for kany years. Ideally you'd rotate them every 60 days. Automating that is hell.
It'd be much nicer if we could just use OIDC with user-configurable endpoint.
In fact, Android implements now on OS level an API for password managers, but no way to easily authenticate through a third party app.
Password managers are "good enough" that few people care about better solutions anymore.
Personally, I'd prefer to see client side certificates, or OIDC login everywhere, with short lived session tokens, and proper U2F 2FA.
With rotation, there is a tendency to just use the same password but increment a digit at the end, or to write them down because people forget them. A password manager helps with this, but if you're using a password manager, then you can use a different password everywhere.
Password rotation was recommended in the days when people used the same password everywhere and had to memorize them because password managers weren't a thing.
Password rotation gains you nothing if you're already using strong, unique passwords. The best it will gain you is preventing your account from being accessed if they have already breached the password file, cracked it, and come back after the rotation period. But at that point they've already had access to the system and your password is meaningless anyway, so you didn't actually gain anything.
Rotating credentials is important, even if you automate them. For the same reason that Let's Encrypt only provides certificates with 90 days validity, and that OAuth2 Offline tokens are usually limited to 90 or 180 days.
Ideally we'd use OAuth2 for everything, as that'd allow proper usage off offline tokens that allow the client to generate short lived session tokens, but we don't, instead we're using passwords everywhere, and we'd ideally want to have the same validity there.
The optimum would even be using challenge response authentications, or client side certificates.
This isn't a comparison of manual password management to password managers, but a criticism of password managers when compared to 30-day rotation cycle of client-side certificates.
In any case, if you really want to rotate passwords, 1Password has a "Security Audit" section with sections for "3+ years old", "1-3 years old", and "6-12 months old" passwords (and duplicate passwords, and weak passwords, and watchtower alerts), so you can rotate if you want to.
Sadly, currently this all is highly theoretical. The first thing we should focus on is getting 2FA (TOTP/HOTP or U2F) authenticated login on every service that doesn’t use OIDC. Even this very site, HN, has no such functionality (@dang, @pg: Why?)
This is a much more important first step, and once that’s fixed, we can look at improving credential rotation, and providing global SSO with browser credentials.
I'm not saying 2FA is bad, but these people like the person above lives in a hilarious bubble if they think a website like HN is missing out by not having it.
It comes off as concern-masturbation, if I may be so vulgar.
By the way, the best thing we did for security across our gambling network is to generate passwords for users. Nobody uses 2FA, and the people that use it aren't the ones that need help. But everyone reuses passwords.
I'm moving to KeepassXC currently and if you use a Yubikey challenge, you (by default) have to press it anytime you save or update a record which is a big pain. I think you can change it but I worry it might crash (I'm running unstable for the browser extension) or I might forget to save
But that can only work if most services you’re using are using SSO, and you rarely need to reauth. I need to reauth every time I log in, every time I want to authorize a new service, or modify server, DNS or storage settings.
This only works well because I’m self-hosting 90% of the services I use, and they use a Keycloak as identity provider, and then don’t have to handle identity themselves.
This is why I’d prefer to see more identity federation – ideally the tokens the services see are short-lived, but the user doesn’t have to re-login every time either.
I think MFA is important and have it enabled for every service that offers it, but we have MFA set up for our CLI access to AWS and I used to let out a volume of curses frequently when my token expired.
I eventually ended up adding a bash alias “damn”[0] that pipes my current MFA token into the AWS CLI so whenever it expires I can just type “damn” and be logged back in.
I like the magic link approach Slack and Medium use - although I have frequently cursed the inconvenience of having to log into gmail.
[0] why damn? Fuck was taken: https://github.com/nvbn/thefuck
I imagine some people use it as a signal - if you support 2FA, you are at least considering security well, even if they don't actually make use of it.
To be clear, you’re aware how absurdly long it would take to complete offline cracking for a single, randomly generated, 128-bit password, right? From a purely statistical perspective, what you’re advocating doesn’t actually make sense. It can only impose usability friction.
Unless you know a site’s password database has been compromised, you shouldn’t change the password. If it has been compromised, your password is so strong that you could honestly let just about every computer in the world try to crack it and still be reasonably confident in its continued security.
Password managers empower you to do that, but with a different password for every single service you use. You set it and forget it because you don’t have to do anything else. Simpler is better for users.
> For the same reason that Let's Encrypt only provides certificates with 90 days validity
I’m sorry, but no. This is utterly dissimilar to personal passwords. Public key certificates have limited validity because digital signatures cannot be revoked offline. The entire premise of a digital signature scheme and PKI is that you default distrust. Therefore, signers must renew instead of revoke, like a dead man’s switch. It doesn’t make sense to use this principle as a comparison for password security, because passwords are a secret used for access control, not authentication in the cryptographic sense of the term.
I think there is merit to the argument that public key authentication is better than passwords, but such a discussion should 1) include nuances, like the differences between authentication and access control, and 2) be mindful of cavets, especially with respect to usability. Under the current paradigm, passwords are not weak just because they do not share the same e.g. rotation characteristics as certificates, because they have very different use cases and threat models.
Suppose it will take 100 years to crack your strong unique password once the file is breached. If the rotation period is 90 days, rotation gains you something. Suppose they got the password file from a database backup. Your password isn't meaningless yet. You'll be fine as long as you rotate it within the next 100 years.
And tada, they got your password.
This is the sole reason why Let's Encrypt does 30-day certificates, and why the session tokens in OIDC are usually a few minutes at most.
The only one that's using a session token without invalidation time, forever, is Uber, and that was heavily criticized last time on HN.
And now, everyone's apparently in support of using the same password as login token for decades, never changing it.
Passwords != session tokens != certificates.
Passwords are a form of access control. I repeat: a strong password cannot be brute forced for billions of years. Even with technological advancements, most strong passwords are well over what’s required to literally be safe for a lifetime.
Certificates are not a form of access control, like I explained in my other response to you. They are a form of cryptographic authentication. Digital signatures cannot be revoked offline, which is a problem because they’re used by other parties for validating trust. Therefore, certificates have a built-in dead man’s switch that requires renewal.
Passwords are not used for validating trust. They’re not comparable to certificates. Stop using certificates as an example of why passwords need to be rotated, because certificates don’t even use “rotation” in that sense of the word.
The topic was never about brute forcing, that’s irrelevant.
It’s always about exfiltrated passwords, certificates or session tokens.
You usually have additional authentication requirements so that changing the password requires more than just the password, but an attacker that exfiltrates the password can still read everything.
For example, an attacker that obtains my onlinebanking password will be able to read all transactions, but not make changes. In this way, the password acts identical to a session token – an attacker exfiltrating a session token will get the same access.
The goal is to reduce this ability – changing the password as often as the offline session token ensures that if an attacker had such read access, as is possible with many services, this access will not continue forever.
With your suggestion, of using an identical password for decades, a potential attacker has for decades read access to the bank account. This is undesirable.
Yes, preventing exfiltration would be better, but exfiltrating session tokens and passwords is identical in terms of attack surface, and as result, they should be protected identically.
A strong password takes billions of years to crack with current computing power, assuming an entire datacenter is coordinating offline cracking on your password in particular.
This isn’t correct. Password rotation is a function of desired cover time (how long you want to maintain confidentiality) and password strength (approximate entropy and complexity).
If you randomly generate a password with 20+ mixed case alphanumeric characters, it’s theoretically safe against offline brute forcing attempts for more time than the universe has existed. Statistically speaking, you gain virtually nothing by rotating such passwords unless you know they’ve been compromised. On the other hand, you impose a significant security liability through usability friction.
Troy hunt, in his ever-long quest of getting copies of these breaches, eventually gets a copy of all of my passwords and adds it to his database, and now suddenly, you the user get a warning, uhh.. this password is in the pwned-passwords DB... and now you know idiotService really is an idiot.
Data source is a python script which trolls through /usr/dict/words and then counts the occurrence of each three-letter alternating-hand combination, outputting the counts. To start I pick a letter with 1/26 odds, then filter the triplets based on first letter, then continuously pick triplets based on the last two selected letters.
(I think this amounts to a Markov chain but I've not studied them well enough to know for certain...)
I think the point is to see if any password you've come up with (either generated in 1password or on your own) has been breached and you don't know it. If you do have unique passwords for everything and you see that it's there, then you would know what's been pwned.
2) get asked to help someone else at their machine
3) need to log-in to a remote resource under my own user to do something
4) password is in the password manager on my workstation on another floor
Solution? Should I:
* ask the person to give very exact and detailed instructions on what they need me to accomplish so that I can do that work from my own workstation?
* go up to my workstation and call the person who needs help and walk him through logging in as me?
* remote-login from their workstation to mine to copy/paste (and hope their workstation's clipboard is secure)?
* bring my password manager with me on my phone (and risk my passwords being pwned because phones are Not Secure)?
* write down 40 character password somewhere (stick-it note?) and hope I neither typo anything, nor allow others to read it, nor carelessly discard it?
* just use a password I made up and can easily remember?
I'm sure there's better solutions. Each one has their own annoyances.
As someone who uses this solution to your above-stated problem, I disagree with the assertion that phones are "Not Secure." Care to back that up?
Low battery requires plugging in a cable to charge; the cable may be a surreptitiously-installed data cable. I do not trust the hardware or software stack that handles the data cable to be secure.
SMS: Not Secure. http://www.cybersecuritytrend.com/topics/cyber-security/arti...
Wifi: Not Secure. https://www.bestvpn.com/privacy-news/wpa2-wifi-not-secure/
Many apps "require" silly amounts of permissions to the phone before they'll install. Apps' ability to read what's on screen, to be notified of clipboard changes, to listen to sounds; all when not even in the foreground. On my computer, I can easily check what apps and background services are running. Not so easily on a phone.
Did you audit the Intel AME, HD firmware, chipset, audio drivers, usb drivers, and everything else on your PC?
This is just totally not true.
I'd wager a fair sum that passwords stored on an iPhone, behind a decent layer of security, are entirely better protected from physical access than on any general-purpose computer.
It's long, it's random, you don't have to look at it, and is easily communicated to someone.
Heck, I do the same for answers to security questions in case I need to communicate an answer to it for whatever reason.
> * remote-login from their workstation to mine to copy/paste (and hope their workstation's clipboard is secure)?
This option also risks leaving around credentials to remote-login to your workstation.
No sense worrying about the workstation's clipboard-security though- if the workstation itself is pwned or intentionally bugged, the password will be at risk from a keylogger or network-sniffing proxy when it's typed in anyway, so no avoiding that risk.
Option B is to ask yourself whether a 40-character impossible-to-write-down-without-typos password, phones are Not Secure level of security-paranoia is worth the tradeoff of inconvenience (it may be, depending on the nature of your work).
FWIW I currently write software which analyzes DNA; privacy and medical issues are real and definite concerns to me.
I've always thought that the best way to build a rainbow table is to create a 'password checking service' like this and have people fill it with their own passwords.
Also, some "long and strong" passwords are too long and/or string for sites that have poor password requirements.
> fracas homily unsaddle bonus pueblo victim
I vastly prefer it.. by leagues. With that said, I rarely use it. For my feeling of security I want to use many word combos, but it's very common for password input services to limit the number of characters I can use. Some of them (shockingly often) even truncate the password and accept it anyway, so now I don't even know what my password is.
Shame.
Boggles my mind...