Unfortunately my company claims their credit card and electronic payment processing agreements require employee password to expire.

If that’s actually true, then most companies hands are tied until those payment agencies update their requirements.

That‘s because these companies, and the regulation itself don‘t have security in mind. It‘s really only about compliance and liability avoidance.

There is no incentive for change. Look what happened with Equifax.

This is true, PCI DSS still requires password expiry.

The trick is figuring out the boundary of the systems that are subject to PCI.

> This is true, PCI DSS still requires password expiry.

We’ve been using a compensating control of “our password policy is exactly NIST SP 800-63B (2017) plus two more characters in Min length” for our PCI audits since the revision was published in 2017.

It’s been accepted three times so far.

Yes. When a policy is crazy, the Right Thing is to find out how to either alter that policy or obtain an authorised deviation from it as tatersolid describes.

If you spend an hour a month on something that's required by policy and in your opinion shouldn't be, then six hours invested finding the person who sets that policy and explaining why it's a terrible idea may free up net six extra hours of your life within a year.

That story where the guy comes down a mountain with a stone tablet with Ten Commandments carved into it is (a) a myth and (b) no kind of a way to set effective policy. People can't even agree on what his Ten Commandments were, let alone on following them.

As always with PCI, it depends on your auditor.

Using NIST password guidelines as a compensating control has been accepted by every assessor I’ve dealt with (even the really bad ones). A compensating control must exceed the requirements of the control its compensating for, and the NIST rules clearly do. I’d say it has much more to do with how you write your compensating control worksheet rather than anything else. If you assessor is refusing to accept compensating controls, you should report them to the SSC, and then find a new assessor.

Yes, if you’re not actually doing the “compare password against breach lists” part of SP 800-63B regularly they likely won’t accept it.

I hope forced expiry will be gone from next PCI revision anyway.

Do you happen to have a library/tool you could recommend that helps with this or did you develop something in-house?

My startup is implementing most of the NIST rec’s with the help of projects like zxcvbn but we would like to also start doing breach list comparisons so figured I’d ask.

We use the NTLM version of the haveibeenowned lists plus a power shell script from https://github.com/MichaelGrafnetter/DSInternals/blob/master...

H8mail on Github and the APIs it connects to.

I think we have it for one of the ISO compliances, too.

The ISO 27xxx standards in Information Security don't tell you how to do it, they tell you how to formalise what you decided to do (and how it can be monitored, audited, etc.). So the reason your ISO compliance forces you to do password rotation is that some twit added "password rotation" to the policies you decided you were going to implement. New task: Find the relevant policy and revise it citing the modern NIST guidance. Extra credit: Go through other policies that get in your way, figure out why they're in there and either you'll be reconciled to this annoyance in your life or you can revise the policy to not be a problem.

I would love to know my companies reasoning. I work for a huge health care provider and everyone from care workers to the nurses in our office have to change our passwords each 6 weeks. Myself and others just keep the same passwords and increase the number at the end. Currently we keep getting these emails from IT telling us security threat level is high and don’t click links from unknown locations. The system is buggy to add to is all so people are constantly getting locked out and they call IT who helps change to another password. After having to do it so often so many times most of us just don’t care anymore. My password is kind of complex and in the middle I have a number that I just increase each time.

I agree with all of this except password managers. If you use a lot of different public computers or temporary work laptops they don’t always let you install LastPass, so I frequently ended up being unable to access my accounts.

I access my manager from my phone and type them in. I would never install my LastPass on a public computer even if they let me.

It would be really cool if you could plug your phone in and it appeared as a USB keyboard device and you could "type" the password from the password manager that way without ever giving the computer access to anything except that password.

Maybe some sort of simple USB dongle (like a yubikey) could be fed by the phone via bluetooth or nfc to do this?

It would be even cooler if I could open an app on my phone, point it at a QR code on screen, and not have anything else bother me

All the QR code needs to encode is a URL pointing to their authentication endpoint. If it's reasonably standardized, any password manager could implement it.

Login would be:

* scan QR code, sees https:/ /megacorp.com/login?session=hexhexhex

* Password manager asks that you want to log in with account X.

* Negotiates with auth service

* Website recieves your confirmed token via websocket

* You're logged in.

And, of course, if you don't have an account, the password manager can get you started creating one.

SAASPASS does this as well.

https://saaspass.com/

This is (sorta) how SQRL works.

https://www.grc.com/sqrl/sqrl.htm

Which, to be fair, is close to how it works inside Apple's walled garden. Logging into iCloud on a new computer will cause the iPhone attached to that account to pop-up a "confirm login" dialog, so the second factor for login is as unobtrusive as possible.

No you still need a password, which also makes it insecure on a public computer (where keyloggers might be installed).

Instead, the better solution would be, you point your phone to a QR code on the computer screen, press “confirm”, the computer is magically logged in, until you then press “log out” on your phone and the computer is logged out.

If an attacker has root on a public computer, a QR code is easily hackable as well: just man in the middle the scan process.

So while you are logged in, the attacker can do anything they want.

The signature of the QR code would need to be accepted by your mobile, not the public computer. I don’t think mitm the QR code process is possible if they sign it. But if the public computer is compromised, anything you log into from that computer is accessible by the attacker anyway, as long as the session is valid.

That’s true regardless of the login method. The benefit of the method I described is that you can 100% log out without any MITM, as you initiate the logout from a trusted device

Yeah, agreed.

Google does that without needing a QR code if you have a recent Android and haven't enabled 2FA

How does the communication from the computer to the phone work?

No idea. Presumably a push notification. Within less than a second providing your email (on fast US data) you get a prompt on your phone that shows the browser model and approx location and asks you to approve or disapprove the login.

They initially rolled it out as a 2FA option, then as an optional for 1FA.

OK so you have to actually type your email into the computer.

Exactly. Google already asked for email alone and then password on the next page so that they could support sending enterprise emails to custom login systems.

You’ve just described SQRL

Yeah, I actually like the way Microsoft and Google do it when it just displays notification or number on my phone. Recently I logged in to a new Windows 10 computer and I didn't even have to type a password anywhere.

Unfortunately I don't see the need to actually fill and type passwords going away any time soon.

I'm mostly complaining about having to either:

1) Install the password manager on a computer to fill in passwords. You end up typing the password manager's password into the computer which could compromise the entire database as well as give the computer other information about your accounts and website usage.

2) Otherwise you have a password manager on your phone. You have to view the password and type it into a keyboard. Typing complex passwords is a pain in the butt. It would be nice if the password manager on my phone could just somehow type it for me. Then the only thing that goes into the computer is the exact password I'm trying to use.

Oh hell that would be amazeballs if it's open source and worked on Windows, OSX, Linux, and could work with a 2FA device like Yubikey. I'd put $20 down for that in a heartbeat.

This seems to be the default for web apps here in China, such as Taobao or JD. Either the home page or the login page presents a QR code, and the mobile app has a scan icon.

Would you sue me if I tried to implement this? That is a amazing idea.

This has been done already, so no. There’s prior art. Look up Clef for one example.

https://en.m.wikipedia.org/wiki/Clef_(app)

I had high hopes for Clef, but unfortunately, it never got the traction it needed.

That would require each site to implement server-side components to talk to Clef, and most sites have been ice age slow to implement basic TOTP never mind yet another method.

Now, if the big existing OAuth sites, your Google, Facebook, Okta, etc implemented a QR code method like Clef then it might work.

I already need to do this to login to LINE on my computer, so no

do it. no one's going to sue for you implementing a random comment brainstorm.

Make sure nobody takes a photo of you showing your qr code I guess.

The QR code would only contain a login challenge, the phone would complete the challenge. Of course that would mean the auth server must be publicly reachable or the phone must be in the same network.

As far as I understood, if somebody else scanned the same token, they would just login with their own account (if they have one).

Whoever logged in first would invalidate the hexhexhex token and the second person would need to start another browser session.

I know of a couple banking apps that use this. super handy!

The EspUSB Tiny can pretend to be a USB keyboard and mouse, and it fits inside a USB socket. I've built prototypes already, and I've found a manufacturer for scaling up, but it's stalled since August because of certification issues.

It wouldn't be hard to add encrypted password storage to the EspUSB firmware. The difficulty is that you need to know the keyboard layout of the destination computer.

Keyboards don't send a letter "A", they send "shift" + "a". If your computer's language setting is French, or German, or Chinese, etc - things get complicated fast.

To make it worse, passwords need to use special characters (not just a-z). Sure, it's not unreasonable to ask you to change the keyboard layout, because you're on Hacker News and are therefore pretty good with computers. But this would limit an average user.

The other problem is that it types the password as plain text, which is a bit insecure. If I have to carry a dongle and change settings on the client, why not make the dongle do some sophisticated key pair exchange with the client app?

It's a good idea for another EspUSB demo app, but I worry that it couldn't find mass market adoption as a product. Without sales of over 10,000 devices, it's not possible to pay off the FCC certification lab, and I haven't got a solution for that.

> The other problem is that it types the password as plain text, which is a bit insecure. If I have to carry a dongle and change settings on the client, why not make the dongle do some sophisticated key pair exchange with the client app?

I kinda prefer simplicity. What if the dongle breaks, gets lost, or some change in the environment makes it impossible to run the client or perform this sophisticated key pair exchange? Locked out, fun.

My keyboard can generate passwords, but I could generate the same passwords on paper (or, more likely, using a piece of software running on some other device) without ever connecting to the device where I'm going to enter that password.

This is why I would prefer a dumb thing that's driven by my phone via a secure channel. I view the alternative as typing my password on the keyboard.

Very doable. I also want(ed) this. There are some old kernel patches on github that extend the android USB driver to also be able to register as an HID device.

I also tried kicking the android driver and just using (iirc) usbfs or what is was called so you could implement HID in userspace and repurpose old phones while kicking android. But the vendor kernel stopped compiling :/

This woul imo be a really interesting application to repurpose old android phones.

I also looked into this but was disappointed when I found that android support for USB HID only goes in one direction. You can attach a keyboard to your phone, but your phone cannot act like one. There are so many useful usecases for a phone like a keyboard it is too bad...

Yeah, this is why you either need to disable the android usb driver and use default linux ones (enabling which, broke the compile for the vendor kernel on my device)

Or patch the android stuff to add HID support: https://github.com/pelya/android-keyboard-gadget

Yes but that rules out making a popular app out of it.

That's exactly what KeoPass[1] does: a biometric key (your fingerprint), that behaves like a no-driver-needed USB dongle/keyboard.

Your grandpa could use it to secure his crypto wallet.

[1] https://www.keopass.com/index_en.html

> Your grandpa could use it to secure his crypto wallet.

For a certain sense of "secure". Because fingerprints aren't. Not just because you leave them everywhere, but because the way we examine fingerprints doesn't have a result that is particularly unique.

Not even at the criminal case-law level [0][1].

That fingerprints are unique is an assumption, but it doesn't match our reality. They're useful for eliminating from a known small pool, not matching against a large group.

Many of the elements we match against run in families.

[0] https://mccoll-law.com/attorney-profile/37-general/38-finger...

[1] https://www.telegraph.co.uk/science/2016/03/14/why-your-fing...

I guess what I wonder about there is how do you deal with various password "rules" when generating the passwords? I really have no idea what that thing is doing. How does it know which password goes to which website? How do you create multiple passwords from your fingerprint?

you can use a teensy. i have a prototype that communicates to a teensy over serial connection and types in a pw from an app. could use wifi or bluetooth too.

Pardon my ignorance but if you're worried about the computer being compromised so that they could somehow access your LastPass, why would you even use it for any authenticated work in the first place?

Having the one thing you logged in to compromised is a lot better than having ALL your logins compromised.

Particularly if you have a working mobile connection. But there are so many work things one can’t do on a smartphone.

They used to have a mobile page you could login to. It was really plain but it did what it did best: provide an easy and clean way to access your passwords when you are somewhere. It was something like https://lastpass.com/mobile ...

It would be even cooler if there were no possible vector for the computer to then compromise your phone, but I don't really see that happening.

That gets old very fast too though. Copying a long and complicated password manually is pretty grim.

And then you've got your phone open, displaying your password to shoulder surfers, for as long as it takes to type in your password.

I have a hard enough time typing 4mfkD.Q.27cC8,'@eG}a4{\* , I am very much not worried about a "shoulder surfer" either seeing the cleartext password on my tiny phone screen, or watching all of those keystrokes without me noticing them.

I'd be more concerned about it getting caught on camera.

You should never, ever, ever type a password on a public computer.

Upvote. You have no way of knowing if that computer is compromised, say with bogus root SSL certificates to allow MitM of ostensibly secure web sites.

What if you store passwords for non-ssl sites in your password manager? I have passwords for some really old mailing lists that don't use SSL and had a big warning that they're completely insecure on the page. I especially don't want to use a shared password if it has a decent chance of being compromised, but if I cared if that account got compromised I wouldn't have set it up.

So basically, you should never use public computers for anything beyond looking at YouTube anonymously?

And searching things that you can't search for at home or on your phone.

The kinds of things that people get put on watchlist for, like where to buy industrial quantities of hydrofluoric acid.

For scenarios like this, where the hardware is untrusted, Yubikey type devices are really the only solution (where the device can present as a user input device, and provide the necessary string secret). Everyone else can use a password manager.

EDIT: If you're on an untrusted device, should you really be putting secrets into it? Maybe not!

Use KeePass on a USB drive with a key file. You won't have to type a password or transmit anything over the internet.

LastPass (like all other good online password managers) has a web UI.

I had an employer that blocked access to lastpass.com to discourage that sort of thing. I guess the idea is you shouldn't be using a work computer for personal stuff and you shouldn't put work passwords on a 3rd part site. In reality, things aren't split that cleanly, so the block was annoying.

Which is why at a previous employer, everyone just stuffed all of it in a spreadsheet, with expiry dates, and last logged in times.

That actually sounds pretty secure, if the computer had a reasonable password and FDE you've just implemented a hacky password manager. Even without FDE you're better than anyone who writes it down on a sticky or uses something trivial.

Unless they're using Excel functions to generate password{n++} . That'd be clever and yet horrid at the same time.

Although at most workplaces your documents are just a folder on a shared drive somewhere, which may not be secured well and in some cases not secured at all.

I used a little php script to do the password generation, and yes we did use FDE

If the script is accessible to other people I suppose you have to worry about it being hacked, especially if you let php get out of date or take input in say password length?

That's an even bigger reason to use password managers. Use a mobile app and 2FA.

You can use the Lastpass site on any computer without the browser extension.

I totally agree that password expiry is a problem, however I have twice taken over AD based systems where there was widespread password sharing, and I found IT knew a lot of passwords of users. I found that a one off change didn't help, they all just updated each other.

So my advice is to advise people that they will get resets. To run them through a couple with increasing complexity requirements. Then increase the period between resets dramatically without telling anyone, so 30 days (Still a novelty), 90 days (less fun), 120 days, 360 days.

I suppose it is a password re-education exercise really. I always remind people that they are welcome to change their password whenever they want (then they will never see a forced reset). I also tell them that my single biggest requirement is that they don't use their Facebook password for work!

I will keep password resets, but nothing like the 90 days PCI DSS still insists on.

In legacy systems shared admin credentials are very common, and while working towards individual logins I tend to rotate these often, since a password manager can be used. It is hard to have individual accounts for everyone at an external support company for instance....

While decreasing rotation frequency is definitely good, I'm not quite sure how is this supposed to help reuse? People will do what they need to to get their job done, exactly the finding of the article. Would be better to tackle the root cause by e.g. having shared, federated accounts or roles. Of course, it's easy to say, but should be worth it in the long run.

Surely the whole point of a password manager is to have a different long complex password for each system you login to without needing to remember any of them but your master password?

What part of the parent comment are you replying to?

I think he means that a password manager (PM) renders the other two points moot. Password expiry? No problem - my PM generates a new one easily. Complex rules? No problem - my PM will follow any rules you like.

My response is that not everyone uses a PM, so the other two points are not moot.

Also, FWIW, I find myself rather uneasy about using a PM, so the other two points aren't moot, at least for me. "One password to rule them all" means that you've created one nice big juicy target that needs to be breached once, versus a bunch of little targets that have to each be breached individually. To take one real-life example, if the TSA wants to rifle through your digital life, it will be much, much harder for them if you don't have a PM.

Sorry but I don’t understand how I’d use a password manager to unlock my computer. This password is for my active directory account and I hate that it expires every three months.

Try to get the AD policy revised. Because there is (since 2017) clear NIST guidance saying not to do this, chances are that somewhere in your organisation a document can be updated to cite that NIST guidance and then the AD controls can be relaxed to let passwords have the same lifetime as the account they're for. Finding who owns this policy and getting them to fix it may take a bit longer than one of those 90 day password changes, but it'll feel like you made the world better and it may only take a phone call or an email to the right person.

Newer Windows AD builds have FIDO2 support, so on shiny new computers you _could_ unlock "your" computer (one you've logged into recently) with a FIDO2 USB key, or a fingerprint reader. That's a much nicer way to unlock a computer you use all the time, while not discouraging you from using a nice long password that bad guys would need to guess or steal to get in from a different machine.

My login/AD password expires every month, and you can't reuse one from the last year. But in the end it's not too bad, because you just append a number to your password and that's it. Most people have a post-it on their screen with the last number they used.

It's useless, but not worth my energy to fight.

So do I, and I manage the AD for my organization.

I'm not too concerned about "one to rule them all" since it basically already exists — my email login. Get that and you have everything.

Well yes, but unless absolutely everyone uses a password manager then you also have to allow non-expiring memorable passphrases.

The one thing I really hate about IT security certifications is that they promulgate these ridiculous "best practices"

Just come to the dark side and learn to program and privilege escalate. You'll learn all these practices and how to circumvent them.