Your passwords are safe as long as you have done your part, i.e. followed best practice on how to set up your passphrase for accessing your information. LastPass implemented a system that is durable, as long as your HW is not compromised or you are somehow duped into giving away your password you should expect your passwords to be safe. If you are worried, change your passphrase in accordance with best practice and you should be fine. Breaches will happen, their architecture saves your data - but that means we have to do our part and follow recommended process/practice.
Password Requirements: Myths and Madness
161–170 of 257 posts
Re: Password Requirements: Myths and Madness
#162It's a good article, but ...
> You cannot use whitespace, accented letters, hyphens, [...] in your password
When test-installing Fedora I use a password which contains some shift number key characters with my UK keyboard. It's a very good test of whether the keyboard encoding is set up correctly in all the places that take passwords. Usually at least one place is set to US keyboard, whatever the user preference.
A password containing, for example @, could cause weird log-in issues later, assuming you're not using a password manager which of course you should be.
Re: Password Requirements: Myths and Madness
#163Earlier quoted context omitted.
I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo. Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home. This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for som…
Windows allows you to use a PIN for regular device logon - so you have a longer, more secure password for general use of the account, but an eg 8 digit numeric PIN _only_ for that device.
That's nice yeah, I wish mac had this too :'(
Re: Password Requirements: Myths and Madness
#164Slightly related (funny, for me) thing I came across recently. I was looking into why some orgs prevent you from changing the Windows domain password if it has been changed less than 24h ago. Turns out there's a reason for this: "Setting the number of days to 0 allows immediate password changes. This setting isn't recommended. Combining immediate password changes with password history allows someone to change a passw…
In other words, someone worked out a way to work around our user- and security-hostile password policy and we can't allow that.
Re: Password Requirements: Myths and Madness
#165In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…
B2B is worse because EVERYONE shares business accounts with other people at the business. And so the usernames passwords and even two factor setups are passed around like coffee. “Oh use bobs login for that, the standard password but add a ! for reasons”
I hadn't realised how many of these logins we had.
The request for a company-recommended password manager came from every department except IT, I think because the companys IT deal with are generally better at supporting multiple accounts.
Re: Password Requirements: Myths and Madness
#166Earlier quoted context omitted.
It’s much easier than ever before. You centralize identity to an IDP and require SAML or OAuth for applications. Then you manage it once. Typically you can get rid of most of the password bullshit by adding MFA, with some exceptions. Unless you’re a DoD contractor or handling taxpayer data the came from the IRS on behalf of a client, MFA should meet or exceed compliance requirements.
I’m a small company and the problem with SAML is that it requires the “enterprise” plan for each app. Slack goes from 0 to $11.75/month/user, Miro goes from $8 to $16. Then you have to pay for Okta (Isn’t it $15/u/m?) For a 5-person business it’s $1185 difference + $900 for Okta, and that doesn’t make me SOC2 compliant (There is a bunch of other requirements, secure access to physical offices, logs, etc.).
sso.tax lists tons of examples of the price increases you’ve mentioned
Re: Password Requirements: Myths and Madness
#167Earlier quoted context omitted.
We had a credit reporting agency (big US one, suffered a large data breach a few years ago) try and insist that we require password expiration for our employees. After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security" they backed off.
Mind sharing those two additional references, for those of us who're still forced to do password expiration?
It's on NIST SP 800-63B 5.1.1.2[1]:
> 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.
[1]: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
Re: Password Requirements: Myths and Madness
#168I have accepted that these sites aren’t going to change their ways. What I’d like though is direct integration with my password manager. Communicate whatever Byzantine password requirements you have via some standard hidden fields or meta tags so my password manager will generate only compliant passwords.
yep this is the way forward, ideally with something like the proposed passwordrules attribute
Re: Password Requirements: Myths and Madness
#169Earlier quoted context omitted.
You could salt the LSH with a different per-user salt.
True, if you were only concerned about similarity with the same user's passwords.
which in this case we are. We don't want to reject a password because it is similar to some other user password.
Mind, I think the feature is misguided, but it is probably possible to implement it safely.
Re: Password Requirements: Myths and Madness
#170> You cannot enter a password with more than X chars
I've seen this from banks, for access to my money & credit...
Both FirstDirect and HSBC used to have a 9 character password for their "digital secure key"s (basically their apps on my phone, in the direct use use-case). 9. Just 9. Though at least alpha-numeric & case-sensitive, so some room for reasonable entropy.
Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security!
(UK here, not sure if they have different restrictions in different territories but I suspect not)