1. 8

    There’s one legitimate use case for password expiration policy that often gets ignored.

    If a password is compromised the attacker can possibly quietly access a system behind a user’s back and siphon out information for years and years.

    For example the CEOs email password has been compromised and a hacker establishes a script to siphon out and archive messages which could last for years.

    A password expiration policy limits this risk by setting a time window.

    If you don’t have that you can potentially get into situations where you can not reliably determine what has been compromised and what hasn’t been.

    Password expiration gives you a frame of reference for when the compromise could and could not have happened.

    1. 7

      The problem with this reasoning is that it ignores the initial attack vector; how did the attacker compromise that password in the first place? It doesn’t just magically fall out of the sky once and then never reappear again.

      Very often you’ll find that the password was obtained by compromising a victim’s computer, breaking into an auxiliary system that shares the same passwords, and so on. In these cases it is absolutely useless to change the password, because the attacker could just as easily obtain the new password and continue their business.

      There’s a small set of cases where a time window might limit exposure, such as reused passwords in password dumps; but 1) these cases are better mitigated by preventing low-entropy passwords, 2) you’re still vulnerable for 3 months or whatever your window is, which is more than enough time to siphon out all information from most networks, 3) you’d be much better protected by just having proper monitoring of user sessions in the first place.

      Is there theoretically a nonzero benefit to password expiry? Yes, but only if your security is already otherwise lacking, and even then it’s not a common case, and at that point it’s absolutely not worth it considering the big downside of forced password expiry: it incentivizes people to pick worse passwords, because remembering complex passwords is a big time investment that’s no longer worth it.

      1. 1

        This would indeed work if you can use a password manager at that point. If it is at the login prompt, you usually can’t use a password manager. If web service X has a policy to change password every Y months, it wouldn’t be much trouble, I just use my password manager. I do that occasionally (manually) anyway for social accounts.

        Also, as the article suggest, for the particular threat you mention, you’d better use 2FA to mitigate that.

      1. 1

        Mmh. Why does PIA not like the community-run and non-profit ISP I use?

        Your ISP: Individual Network Berlin e.V. You are not protected Learn More »

        1. 9

          Because PIA is a VPN provider, and VPN providers are in the snakeoil and fearmongering business.

          EDIT: To be clear, this isn’t just a random rant. I mean this entirely seriously. The entire VPN provider industry runs on lies and misrepresentations about what a VPN service does, exactly. It’s nothing more than a proxy, with all the same security and privacy issues: https://gist.github.com/joepie91/5a9909939e6ce7d09e29

          1. 1

            Pretty much dead on. They’ll only change that line if they see that you’re coming from one of their VPN servers. Anything else and “You are not protected.”

            1. 1

              And the irony is that I connect to my ISP via VPN :)

          1. 3

            It sounds to me like “the desired out come [sic] of a very short URL” needs to be examined: What is so wrong about a long URL? Google use them, and Apple use them. As a content-identifier, a URL should (conceptually) be a hash of its content and accessor, and so very compressed hashes for mostly public information (like on Twtitter) are absolutely acceptable. URLs can get quite large these days, and long URLs may scare people giving them pause before sending them to others. For all these reasons and more, I’d really like to see this point justified further.

            However even given that, there’s other strange advice in here as well, like “Do not use obfuscated URLs as a backdoor.” which is silly. A long, hard-to-guess URL is absolutely more secure than a short, easy-to-remember (and frequently-typed) password.

            And the proposed protection against timing attacks is troubling in the face of a much simpler solution: Find the max lookup time, and sleep up to it. Add some random fuzz to protect against jitter.

            1. 2

              A long, hard-to-guess URL is absolutely more secure than a short, easy-to-remember (and frequently-typed) password.

              This is false. The problem is that you’re only considering the raw entropy, but not all of the other technical implications - because a URL is not considered sensitive information, it may be retained by proxies, in access logs, browser history, desktop session data, and so on.

              It may be sent over a message bus like DBus, or through custom IPC protocols to other applications on the system. Browser extensions may even send this URL elsewhere for purposes like malware scans, because they don’t expect the URL to essentially contain a password. And so on - the possibilities are endless.

              This would be a good moment to invoke this article. Deviating from the assumptions under which something is designed, is generally a bad idea because of pitfalls like this.

              1. 1

                a URL is not considered sensitive information,

                And you a password is? That’s so cute.

                Should I address you? Or the person working the sock puppet?

                It may be sent over a message bus like DBus, or through custom IPC protocols to other applications on the system.

                That’s no different than any keychain or password manager.

                Browser extensions may even send this URL elsewhere for purposes like malware scans

                No, they don’t. But it’s not like they’re smart about security, it’s that they’re smart about the privacy backlash. Software that works that way is illegal in Germany and Switzerland, and about to be made illegal (GDPR) in the rest of Europe.

                If you know of a browser extension that does this, you should have it reported.

                And so on - the possibilities are endless.

                No. They’re really not.

                Meanwhile, the very real risk of someone having to remember “yet another password” writes it down with all their other passwords – know an attacker knows by searching for that password which file contains all of the other goodies. Yum.

                Or someone decides to change the password. Or reuse it. Or copy/paste it and accidentally paste it into the wrong place.

                We have too many passwords and I get it: we think we want to “make things secure” instead of authenticating and confirming authorisation to resources. But that’s just caused by too many cargo-cult programmers who find one blog post they agree with and forget how to think for themselves.

              2. 0

                It sounds to me like “the desired out come [sic] of a very short URL” needs to be examined: What is so wrong about a long URL?

                SMS. You only get 160 characters, and you want as short of a URL as possible. This is the sort of constraint I’ve had to work around for clients in the past.

                However even given that, there’s other strange advice in here as well, like “Do not use obfuscated URLs as a backdoor.” which is silly. A long, hard-to-guess URL is absolutely more secure than a short, easy-to-remember (and frequently-typed) password.

                That depends on whether or not you allow weak passwords.

                And the proposed protection against timing attacks is troubling in the face of a much simpler solution: Find the max lookup time, and sleep up to it. Add some random fuzz to protect against jitter.

                Do not use sleep to mitigate timing attacks. It might seem tempting, but it doesn’t work. You either use too short of a delay (and your random fuzz becomes useless with enough samples) or too long of a delay (and expose your server to easier DoS attacks). A Goldilocks strategy won’t work either: the goalposts will move over time, and you’ll need to figure out where/how to calibrate the values for the delays. You’re better off solving the real problem.

                1. 1

                  SMS. You only get 160 characters, and you want as short of a URL as possible. This is the sort of constraint I’ve had to work around for clients in the past.

                  160 characters is plenty for authenticated secret-key encryption.

                  Do not use sleep to mitigate timing attacks.

                  Yes, do. And in fact read the article you just linked to where it suggests exactly my mitigation suggestion: “Make the operation take a minimum time (clamping)”. It suggests a weaknesses to local users and some handwaving about security by obscurity, but no real actual problems with it.

                  [too long of a delay] and expose your server to easier DoS attacks

                  Saying “easier” is intellectually dishonest. If someone can DoS your cpu idle, then they can certainly DoS you when your cpu is warm. Process and network utilisation remains almost exactly the same, and in all practical ways of measuring it, you’re introducing no new attacks.

                  That depends on whether or not you allow weak passwords.

                  The weak password is the one that someone has to write down in an accessible place, but by all means: put your money where your mouth is and find my secret url.

                  Just stop using passwords.

                  1. 1

                    160 characters is plenty for authenticated secret-key encryption.

                    Yes, but not “a custom message + the URL”, which is what my past clients wanted.

                    Saying “easier” is intellectually dishonest. If someone can DoS your cpu idle, then they can certainly DoS you when your cpu is warm. Process and network utilisation remains almost exactly the same, and in all practical ways of measuring it, you’re introducing no new attacks.

                    The DoS comes in when you have idle connections being used (and using memory) for needlessly long periods of time, which allows an attacker to send more requests than the server can fulfill which blocks legitimate traffic.

                    Having a long sleep on the server side makes that easier.

                    I wouldn’t be so quick to call something intellectually dishonest, because all that does is hamper understanding and make future interactions needlessly adversarial.

                    1. 1

                      Yes, but not “a custom message + the URL”, which is what my past clients wanted.

                      Two messages are cheap.

                      Anyway, I try to avoid making things harder for myself since I’m trying to save my customers their money.

                      for needlessly long periods of time, … I wouldn’t be so quick to call something intellectually dishonest, because all that does is hamper understanding and make future interactions needlessly adversarial.

                      You keep saying “long”. Be specific. Give timings: This is usec and nsec territory. An attacker that can overload you taking T+100 usec but not T usec doesn’t exist.