221–230 of 257 posts
With a very large user database, a 256 char entry field would really start to add up, wouldn't it? iirc the DB takes up that room whether it's fully used or not. Size affects not just disk but also bandwidth, memory, cpu, and has an overall effect on system performance
Earlier quoted context omitted.
Passkeys, which are getting closer and closer to prime time. If you think about it, key-based auth is already highly recommended and utilized in many scenarios (like SSH, signing data, certificates, token authentication for use between servers, etc.)… this just makes that accessible to users. The vast majority of people don’t even use a password manager, and use variations of the same password everywhere. That’s real…
Passkeys aren't immune to phishing. And they are susceptible to being lost. I say that as someone with two. Worse, they aren't accepted everywhere. And often places only let you have one registered. :( So, yes, I agree that they are a solution. I don't know that I feel much safer using one, though. And, at large, I can see how they are not much different to passwords. Just ones that you can't speak others easily.
It builds upon WebAuthn and physical keys but is slightly different and on track to be supported by major platforms.
Sounds like you’re referring to something like YubiKey, it’s hard to lose device associated passkeys.
How would you phish it? The challenge response mechanism contains the requesting origin so it’s berry difficult to phish it out given up to date browser.
Earlier quoted context omitted.
I'm afraid to ask what you think are the better ways? My assertion is that most risk of online fraud is a social, not a technical problem. As such, it will require law to make safe.
For example, asymmetric key pairs. Give sites a public key and auth by signing something with your private key. You can use the same key on as many sites as you want, but you can also use different keys for different sites. No need for a third party even.
> please allow long passwords at least 64 chars long; even 256 should pose no DoS risk whatsoever With a very large user database, a 256 char entry field would really start to add up, wouldn't it? iirc the DB takes up that room whether it's fully used or not. Size affects not just disk but also bandwidth, memory, cpu, and has an overall effect on system performance
In 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…
Earlier 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.).
Totally hear you re the cost, it depends on the risks you face. I’m in a bigger enterprise, but for me, no SSO, it is out in 95% of situations. In the exceptions we have, we require vaulted passwords.
A breach would put me out of business, and identity is a key security control for many risks.
Earlier quoted context omitted.
Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at…
The same problem can happen with eight-char passwords. I could pick the same eight chars I like all the time and reuse passwords. You cannot fix password reuse that way. I'm not advocating for emoji passwords, it was just a discussion about password strength vs length.
As others have mentioned, there's no way to fully evaluate password strength short of providing your own entropy, so while the distribution is an important one to know about there's not much we can do to apply it while retaining a traditional password model.
NIST has some recommendations[0] that can detect when a password is not strong, such as checking a list of cracked passwords, but we can't prove that it is.
[0] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret
I recall a talk at passwordcon by Per Thorsheim where he pointed out that not only does the password: "Password2022" meet most "strict" criteria (three different character classes, longer than eight characters) - and -it's amenable to yearly demands for changing (increase the year) - but in large organizations you're actually very likely to find a user or two with this password (as seen in audits that ran simple brut…
> please allow long passwords at least 64 chars long; even 256 should pose no DoS risk whatsoever With a very large user database, a 256 char entry field would really start to add up, wouldn't it? iirc the DB takes up that room whether it's fully used or not. Size affects not just disk but also bandwidth, memory, cpu, and has an overall effect on system performance
Earlier quoted context omitted.
> it certainly does not reduce the security. Yes it does. The more often you have to pick passwords, the more likely you are to pick weaker ones. > We all deal with "password rotation" in real life and it's inescapable: credit cards expire. And to be fair I'm perfectly fine with that because I know a leak from 10 years ago can no longer affect me. I almost wish they expired earlier. When a credit card is about to exp…
> doesn't the new one the bank sends you usually have the same number? Never happened to me using several European banks. Either way the date and CVV change so that's part of the new password. > Yes it does. The more often you have to pick passwords, the more likely you are to pick weaker ones. I don’t think so. People will just change the number at the end, it's not like they will stop using aDgTGdE and start using…
If the minimum password length is 8 and the last two characters are the current month or year, the actual password length is roughly 6.