11 ms·

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, insuranc

• patrickdward 4y ago
  sad but this is too true
• MaxGabriel 4y ago
  You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
  • Obscurity4340 4y ago
    Why are special characters bad practice? Wouldn't they increase the entropy better than numbers?
  • BlueTemplar 4y ago
    I have had trouble convincing people before, would you happen to have a link ?
    • deleted 4y ago
      [deleted]
    • lelandfe 4y ago
      https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret They refer to it as a “Memorized Secret“. The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions: > composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe
      • varenc 4y ago
        From this doc: https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html There’s also this great quote: Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). There’s other great stuff in there as well like that you should allow users to “paste” passwords and potential passwords should be checked against a list of known bad ones.
        • Bilal_io 4y ago
          Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.
          • Aeolun 4y ago
            It’s the absolute best way to make sure all your passwords are insecure garbage.
          • eastbound 4y ago
            My former company required not to use one of the last 10 passwords. So every 3 months, employees did the 11-password dance, setting the password back to the original one.
    • deleted 4y ago
      [deleted]
    • kyrra 4y ago
      https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html > Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. 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.
    • deleted 4y ago
      [deleted]
  • rqtwteye 4y ago
    NIST is pretty good to convince people
  • mijoharas 4y ago
    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.
    • fragmede 4y ago
      Mind sharing those two additional references, for those of us who're still forced to do password expiration?
      • imnotjames 4y ago
        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 https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
      • mijoharas 4y ago
        Sure! I used NIST[0] (which has already been posted here), along with Microsoft[1] and the UK National Cyber Security Centre[2] (we're in the UK as well as the US). For context, I remember the contract first came back, and we redlined it saying we're not gonna do password expiration and explained why. It then came back with another draft and they said "no, this is our policy, you definitely need to do password expiration" so I threw these references together and expanded my explanation. It was a bunch of business/lawyer types, so I threw microsoft in there as I assume they're better known to non-technical people and the other two references are obviously more salient to technical people. As a side-note I think this was _after_ they had their very well publicized security breach, and I would have hoped that they had taken a look at their security and updated their policies but I guess that wasn't the case. I don't know whether they ended up removing it from their contracts going forward or just made an exception for our one. The cynical part of me says the latter (it's a big firm, and we're not a particularly big one) but I can hope. I also recently read an audit for another third party we were evaluating to work with. I raised it as a non-blocking concern saying they're not following modern password standards, and I think if everyone does that these companies will start to update their policies but for now it's fairly common at least in my industry. [EDIT] I went looking for what I actually said to them, and it was "as per UK/US government and Microsoft password guidelines, we will not agree to this, and would prefer if you didn't do it as well.". So I guess I was a bit exasperated with them at the time :) [0] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver [1] https://learn.microsoft.com/en-gb/archive/blogs/secguide/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903 https://learn.microsoft.com/en-gb/archive/blogs/secguide/sec... [2] https://www.ncsc.gov.uk/collection/passwords/updating-your-approach https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
  • x-complexity 4y ago
    This is likely the best way to deal with the inertia exerted by antiquated requirements: Most (keyword being 'most') businesses tend to follow the rules laid out by authorities, so an appeal to authority works in this regard.
  • jjav 4y ago
    > You might be able to appeal to NIST standards, Agreed, huge thanks to NIST for the sane password policy recommendations. While it is still an uphill fight to bring sanity into this mess, being able to quote NIST and say we're following their recommendation has been very helpful.
  • bombolo 4y ago
    usa armed forces still require all the convoluted rules (unless a key is used instead of a password)
  • Sammi 4y ago
    I was able to vastly simplify password requirements in a medium sized US company after appealing to the NIST standard.
    • kings12 4y ago
      [dead]
  • _dain_ 4y ago
    Across the pond, there is also the NCSC password guidance. It's better than linking to some obscure paragraph in a standards document; it's written in plain English, aimed at the layman, and explains exactly why the old doctrines are bad: https://www.ncsc.gov.uk/collection/passwords/updating-your-approach https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
  • patrakov 4y ago
    You will get this reply: "NIST is an American institute, and we are a Japanese company, we have our own standards that differ, and must follow them".
  • Haegin 4y ago
    I work for an insuretech startup and have been through a number of compliance gauntlets with large enterprise insurance companies. Appealing to NIST recommendations for why we don't auto-expire passwords every x days and don't require anything more complicated than at least 10 characters has worked on every occasion.
  • archi42 4y ago
    The topic of "what should we do about our password policies" sometimes comes up with our customers as well. Pointing to NIST and if pressed giving my opinions on good passwords and the use of 2FA (which is largely paraphrasing NIST recommendations anyway) made every customer happy so far :)
• csydas 4y ago
  > The problem is that the demand isn't being made by security professionals, it's being made by risk management people I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These checklists are pushed on regulators who likely lack any ability to assess the validity of such requirements, rubber stamp the checklists into regulations, and now you have a series of unenforceable or ridiculous security policies and practices that basically serve to frustrate the user while failing to prevent actual attacks. I've been at companies where there were rather interesting policies like - Three factor authentication (because a single method isn't enough for some reason) - No password managers allowed (how this is enforced is completely unknown) - 6 week password lifetime - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) - Random character requirements/limitations (you must use non-letter characters from set X, but not from set Y, and absolutely only latin letters) And those are just some of the bangers surrounding password policies; the less said about the network security policies and antivirus policies the better. And these requirements don't come from some regulation/risk assessment group; they're enforced by such groups, but the actual requirements come from some security firm that sell lists and a stamp of approval once you have every box checked. It's difficult to not look at such firms as swindlers with a guaranteed paycheck from a captive audience; they sell their services to regulators as a benchmark to meet, and then in turn they sell implementation services to companies that are forced to meet said regulations. And the end result is just extremely frustrated users who still end up falling for "Hey Bob check this out" phishing emails which is plenty for an attacker to get in and jump around your network until they compromise enough of the environment to take the business down. But hey! The business followed the checklist, so they can't be held liable for exfiltrated data!
  • nulbyte 4y ago
    > - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.
• wkdneidbwf 4y ago
  security theater
• Spooky23 4y ago
  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.
  • deleted 4y ago
    [deleted]
  • eastbound 4y ago
    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.).
    • ethanzh 4y ago
      sso.tax lists tons of examples of the price increases you’ve mentioned
      • eastbound 4y ago
        I love that! Needs to be more known, it’s like SSL certificates when LetsEncrypt didn’t exist. Edit: It has been posted 7 times in the last year.
    • Spooky23 4y ago
      Usually it makes sense to use Google or Microsoft as an IDP vs Okta. 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.
  • 4y ago
• bombcar 4y ago
  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”
  • vanviegen 4y ago
    That's what you get when vendors charge per seat.
    • bombcar 4y ago
      I have a sneaking suspicion that Salesforce is pushing 2FA so hard to sell more seats. And $6k/yr/pop it’s gotta be tempting to share a password …
  • Symbiote 4y ago
    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.
  • nicoburns 4y ago
    We setup bitwarden at work, and it was absolutely fantastic for these sorts o shared accounts. You could have all the password be telling random strings, and control who had access to them with a convenient UI. Password rotation became a lot easier too, because all you had to do was update the password in the password manager and everyone would have the new one.
• lttg 4y ago
  I was in charge of password policy for a healthcare app. We tried to use phrases, often cited as more secure than character/length requirements. The doctors hated it. They didn't understand what a phrase was, it was too different from every other system they interacted with, and it was extra cog load in their already busy days.
  • nicoburns 4y ago
    Why not just have a length requirement and recommend a phrase? “Passphrase” isn’t that common a word, so it merits an explanation. But “your password has to be long, but you don’t need to use special characters, and can use regular english word if you want” is surely easy enough to understand.
  • puffoflogic 4y ago
    > it was too different from every other system they interacted with Translation: they couldn't use the same standard password they use for their banking, their email (also used for 2fa), Facebook, and this porn site they found by clicking on a pop-up ad.
• js2 4y ago
  My company requires us to change our password every 90 days due to such externally imposed demands so mine ends in two digits which have been counting up for almost ten years now.
• randerson 4y ago
  Hopefully the B2B at least makes the password rules configurable per customer. Big Customer X can have what they ask for without hurting all the other customers.