SoylentNews is people
SoylentNews
WSJ: What Keeps People From Using Password Managers?
No pay wall: https://archive.is/HCtcT
Many of us are vulnerable to hackers and eager to secure our online accounts, but lots of us also refuse to use an obvious solution: password managers.
Why? Our research has found that the typical reassurances and promises about password managers just don’t work. Fortunately, our research also suggests there are strategies that can persuade people to get past the psychological barriers and keep their data safe.
[...] In a study I conducted with my Ph.D. student Norah Alkaldi, we found that the two most common methods of persuasion were ineffective in getting people to adopt password managers. The first is the “push” approach—the idea that by showing people the dangers of using simple passwords, recording passwords on their computer or using the same passwords at different sites, we would push them to adopt a safer approach. Users, we found, don’t respond to the push strategy.
[...] The other, “pull,” approach—focusing on the positives of password managers—didn’t deliver any better results.
[...] We discovered two types of “mooring factors” that keep people from changing their behavior.
[...] First, there was the effort required to enter all your passwords into the password manager.
[...] People also fear they will lose all their passwords if they forget their master password.
(Score: 5, Informative) by edIII on Friday June 18 2021, @11:47PM (2 children)
I don't think people should be coming up with passwords, other than the master password, and even then, not all of it. My master password is a combination of high-entropy noise plus a couple of phrases. All chained together for 60-90 characters.
My own "password manager" is a VeraCrypt container in multiple levels with dummy passwords I leave out in the open. I print it and leave it inside my desk, or under the keyboard. Then if somebody finds the VeraCrypt file they will open it up and get a whole bunch of what appears to be security credentials and confidential data.
The real password to the container is contained elsewhere as a physical backup, but not in an easy or even intuitive place, nor does it readily appear as a contiguous password. It's more or less a hint just for me in multiple parts as a backup for my memory as I get older.
Inside the container are a bunch of SSH keys, passwords, and scripts. I run the scripts to open shells on remote systems, and display passwords for websites and other systems. I then use copy/paste, which I realize isn't the most secure way to do it. Requires a lot of trust in the machine, which is why I like using virtual throw-away systems. So I'm pushing the security credentials from a higher system into a lower system, so to speak. When I'm done, the lower system is destroyed and doesn't retain anything.
When I need a new password, or to regenerate one, I use crpytographically secure methods of generating high-entropy passwords.
I take that and pipe it to a file that records the security credentials. I treat all security questions as just another field needing high-entropy noise.
Ironically, all of that is heavily compromised by the fact anybody can request a new password with the ubiquitous forgot-my-password process. So in the end my passwords are only as secure as my email systems. The moral of that story is that passwords alone, no matter how they are stored, are crap.
All websites and systems that use passwords need 2FA or rotating OTP codes similar to the way Google does it. If I want to reset my password, then I need to take one of X number of codes and use it in conjunction with 2FA and email verification (verification I can access X system).
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 1, Funny) by Anonymous Coward on Saturday June 19 2021, @01:23AM
> I treat all security questions as just another field needing high-entropy noise.
You mean your favorite animal when you were 12 was not a 5aff8f2tthhcFR2f00?
(Score: 2) by Rich on Saturday June 19 2021, @02:24AM
You lost me there. I had to read that twice before (I think) I understood it. Point is, you have an elaborate process for your credentials that is way over the head of common users and even for people with security knowledge is rather inconvenient. But even having to look up a sufficiently safe password from a piece of paper and typing it is inconvenient enough.
The corporate people work around that with smartcards that have to be put into the keyboard to authorize the user, but again, that relies on the hosting machine being uncompromised - if it is, every kind of nasty shit can be done behind your back, and with your genuine authentication.
The TFA smartphone banking apps have a somewhat sensible process. Whatever is supposed to be done (e.g. a transfer) shows up on the phone and then has to be unlocked with a simple PIN or password. Still, a dedicated attacker could compromise both devices and send your savings to Fraudistan.
For a solidly secure process, the device holding the password would need to be so trivial that it is free from attack vectors. That means a microcontroller with limited storage that ideally has shown over years that it resists simple hardware attacks like glitching. It would delete its volatile contents upon tamper attempts, but there would be a printable backup that could be typed in from paper, a bit like the hex dumps of old gaming magazines. Restoring will be inconvenient, but it is a guard against loss or catastrophic digital failures. Another paper will contain a simple 128-bit master key that can NOT be printed and has to be handwritten. Passwords will (usually) be generated by the device.
The device has to look (somewhat?) like I described in the thread start, but it has to be rugged, so it can be carried on a physical keychain, much like a house or car key. USB might work, but a MagSafe-like attachment to a little cradle would be more convenient. No radio functions, because of paranoia. Key or cradle would annoyingly beep when the computer is shut down and the key is forgotten. So while you are at the machine, all you have to do is acknowledge TFA requests with a button push, or for typed passwords dial to the target and push the button. If a work session is over or times out, or whatever, you have to once enter the pin. (Assuming an encoder wheel, there would be two or three numbers from 00 to 99, which could be quickly hit; this would avoid to have a keyboard on the device. The alternative would be a keyboard with such a device built-in (SO close: https://www.youtube.com/watch?v=vOa5-NTIvZ8 [youtube.com] gg. Feasibility could be tested with a RasPi 400 or a USB converter for an old PS/2 model M with a little display hooked up. Nice Arduino project idea...)
Short of such a device, I don't see a sensibly secure and convenient solution. One might try to simulate the device at kernel level. Re-do the keyboard driver, so no one outside has direct control over NumLock and CapsLock. Detect a key combination that "launches" the device (or maybe respond to TFA). When that happens, NumLock and CapsLock flash alternatingly (like old airport boarding signs, and that is suppressed in a way that other software can't do exactly that). You'd have hardware verification that a request is legit, but then safety gets into the realm of an ordinary well done password manager that runs as root.