Live data from Hacker News

49% of workers, forced to change passwords, reuse same one with minor change

grahamcluley.com

201–210 of 316 posts

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#201
post #182

Earlier quoted context omitted.

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.

You’ve just described SQRL

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#202

Earlier quoted context omitted.

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.

As always with PCI, it depends on your auditor.

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#203
post #37

Earlier quoted context omitted.

My argument for password expiry (300 days here) is my users have complained they can't keep using the password they use everywhere else.

They can they just have to wait. At my previous role I added a number and kept increasing until it accepted the orginal password and I started the cycle again.

I never wrote my password on a post-it on my screen. The post-it had tallies of the number of times I'd incremented the number at the start, and the number at the end.

And I worked on my IT department, and then went over their heads, until they got smart about password expiration.

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#204
post #158

Earlier quoted context omitted.

I've heard of banks setting a 8-character limit on password length. If my bank did that, I'd be searching for a new bank. Just just reeks of passwords being stored in plain text.

ING Australia [1] only supports a four-digit PIN. Seems to work fine for them; I haven't heard of anyone losing money as a result. [1]: https://www.ing.com.au/securebanking/

4-digit PIN with probably lots of protection/detection against bruteforcing (e.g. you only get 3 tries before you're locked out, then you have to go physically verify your identity and change the PIN again) and it's a bank so naturally everything is already being monitored.

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#205

This should not be a surprise, as this supports the NIST's revised recommendations (from June 2017!) that passwords should not expire [0], because it actually leads to less-secure passwords for this exact reason. Furthermore, many corporate systems do not integrate well with password managers, such as when first logging in to your system in the morning. This means that the password is likely to be one of the few that…

So I was going to ask a variant on that question... How many businesses do you know follow NIST's new password guidelines?

My dayjob in the banking industry is strictly NIST SP 800-63B compliant for all systems we control.

Our industry partners, who are mostly large banks, have idiotic make-work policies. Some are just plain made up without justification by an internal auditor who thinks they’re smart. More than one even consider usernames to be secrets and one threatened to bail on a contract when our apps began displaying the username on-screen and in audit reports.

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#206

This should not be a surprise, as this supports the NIST's revised recommendations (from June 2017!) that passwords should not expire [0], because it actually leads to less-secure passwords for this exact reason. Furthermore, many corporate systems do not integrate well with password managers, such as when first logging in to your system in the morning. This means that the password is likely to be one of the few that…

Just FYI, you have excellent memory. Most users can't remember their 6-8 character alphanumeric.....

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#207

I did this at my old job where they forced regular PW changes. The thing that changed was the string of digits at the end, which was always the year and month I was last forced to change it. Of course, for my personal logins I use a manager and unique strong passwords, but they gave me no reason to care about password security and a bunch of reasons not to. Honestly I'm surprised it's as low as 49%.

> The thing that changed was the string of digits at the end, which was always the year and month I was last forced to change it.

That's good, I just increment the last digit.

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#208

Earlier quoted context omitted.

Schneier says "don't make people change their passwords unless there's indication of compromise" I make the assumption that the longer a password exists, the more likely it's reused and compromised. I don't have insight into every password dump, but I know my users reuse passwords a lot. I think a long expiry is the best balance in my environment.

The point though is that if password changes are required, even with a long expiration time, people are only going to make minor and probably predictable changes to their password. If if you did a 1-year password expiration, and last year's passwords were compromised, then if the attacker figures out that someone's password last year was "uwethskjv9j29#18", then there's a good chance that the attacker is going to try…

> The point though is that if password changes are required, even with a long expiration time, people are only going to make minor and probably predictable changes to their password.

More significantly, if changes are required or weird composition rules used, people are more likely to store their password in a convenient unprotected form (historically, often paper kept next to their main computer, which is a risk, but these days the convenient form may itself by subject to remote compromise, making an even bigger risk.)

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#209
post #136

Earlier quoted context omitted.

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?

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 a…

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...

Re: 49% of workers, forced to change passwords, reuse same one with minor change

#210
My most memorable policy as an end user was as a consulting client for a huge bank. On top of the usual length, character type, and password changing requirements, the password could not use substrings of 3+ characters from any of your prior passwords.

They were also required to pass a black-box “complexity” algorithm, and the vast majority of passwords generated by my password manager inexplicably failed this bar.

So every 6 weeks I would set aside about 20 minutes to generate new passwords of varying length in my password manager until one would be accepted as the new password.

Post reply on HN