[Feature Request] [Discussion] Reset forgotten password in login screen

Brainstorm
21

First off, self-service password resets are considered questionable security (ask Bruce Schneier if you don’t believe me:

https://www.schneier.com/essays/archives/2005/02/the_curse_of_the_sec.html

) because they lower the total security. If it’s easy for the user to remember the answers to the three questions even though he’s prone to forget the password, then it’s that much easier for an attacker to find out that information and break into the user’s account through “password recovery”.

Sure, in your proposal, it’ll result in the user’s password getting changed, which he should notice - but the very premise was that the user is likely to have forgotten the original one, anyway …

Having that said: If there is to be a password reset method, I’d say that it should be implemented in the Portable Authentication Modules (PAM); unfortunately, my PAM-fu is not up to the task of saying whether it can be done with only configuration, or requires writing a new module.

PAM is what forces users with an expired password (see shadow(5) manpage, in particular, 3rd and 5th field of /etc/shadow lines) to set a new one, the result being that it works equally when logging in to a text console, doing a remote login via SSH, and presumably others (maybe even SDDM?) as well. (I have to admit that the SSH route insists on throwing you out and requiring a second try at logging in after having set a new password, though.)

The job of SDDM (and other login interfaces) then wouldn’t be to implement the entire process itself, but merely to understand and display the format of that PAM module’s user-ward I/O.

1 Like
22

That’s true in online services, as Schneier himself, whoever this gentleman is, states in the very first sentence of his article. If an online service has the 3-question method, an attacker with plenty of time could even gain access using logic or if he knows you. That’s why nowadays this method is almost abandoned on most modern web services in favor of OAuth. On a local computer, where an attacker must be literally seat in front of your computer, the lesser of your problems is if they can hack your PC, IMO. There are situations where an attacker can have physical access to your computer (on a public place, a family member, etc) but he won’t be so calm as you can return in any moment, and SDDM blocks the login process after N consecutive failures, so if the 3-question method would be implemented, something like this could be implemented as well.

Yes, the premise is the user has forgotten the password, so changing is, in my opinion, better than remember it, because it is a more secure method, and easier to achieve.

Correct me if I am wrong, but it sounds to me like that PAM’s renewal mechanism first asks for the current password before renewing it. At least when trying to change my own password as my own user through passwd command.

$ passwd                                                                                                                                                                                                                                                                              
Changing password for malevolent.
Current password: 
passwd: Authentication failure
passwd: password unchanged

But running passwd as root, doesn’t ask for the current one

sudo passwd malevolent                                                                                                                                                                                                                                                             
New password:

My PAM-fu is a bit rusty, but I think passwd has a good implementation of PAM, at least local and LDAP modules, which are the ones I’ve worked with.

I’m not a developer, so in my mind if SDDM is able to call passwd command impersonated as root, it would be a breeze to overwrite the user password. But I have no doubts a real programmer would have another approach that I can’t even imagine.

23

Ultimately this proposal makes sense in some form. Passwords are the worst aspect of computers for normal people; they constantly struggle with this, and are forgetting and resetting their passwords all the time. It’s a real problem.

In a home setting I feel that going passwordless with auto-login is best a lot of the time, with any truly sensitive data being in a Plasma Vault. This is what you would want for a shared family media center PC, for example.

But for a personal machine that’s used for private email, online banking, taxes, etc, a very basic amount of security is appropriate–just enough to prevent nosy children or guests from casually snooping on information that’s very private and sensitive.

I think this is the use cases for a “let me reset my login password” feature.

2 Likes
24

Yes, that is the exact scenario where this option should be useful.

25

Correct me if I am wrong, but it sounds to me like that PAM’s renewal mechanism first asks for the current password before renewing it.

Uhhhhh … I actually suspect that that might be passwd(1)'s own code doing that. Based on nothing more than the fact that I see a line
auth sufficient pam_rootok.so
in /etc/pam.d/{chfn,chsh,su}, but not /etc/pam.d/passwd …

But running passwd as root, doesn’t ask for the current one

(Correct, the relevant trigger is to run it as root, not that your example changes the password of root.)

if SDDM is able to call passwd command impersonated as root, it would be a breeze to overwrite the user password.

Definitely (as long as you can navigate appropriate changes in SELinux), but as I said, the way more portable implementation would be to have a PAM module care about those details (where to store Q&A, how to protect them against snooping or manipulation, will you have to register new Q&A after each use, yadda yadda) and make SDDM (and SSH and getty/login and …) provide the necessary user I/O to it.

1 Like
26

@malevolent I guess a valid request would be for sddm to support google authenticator (see link below). Although google authenticator is supposed to be used as 2fa authentication, you could probably assign empty passwords to users and then have them to just use google authentication through their mobiles

I’m not sure what needs to be done to sddm to support that. Maybe it is just as configuration thing (just modifying various files under /etc) after all. :roll_eyes:

27

I might start to sound like a broken record here, but since “Google Authenticator” is in fact TOTP (with the most-frequently-used parameters, like 6 digits and generating a new token every 30 seconds) and a PAM module for that exists

https://wiki.archlinux.org/title/Pam_oath

all that it should take is to a) install the module, b) insert it into the relevant PAM configs (more details on that page), c) register the secret for your user, and d) make sure that SDDM can handle the additional / changed dialogue with the user.

28

… as the very first reply on the Github page you referred to said already. Sorry for the noise …

29

I actually didn’t read it :smiley:

I just mentioned it to make the @malevolent aware of that alternative. It’s not what they asked for (ability for a user to reset their password) but it solves the same problem (users forget their passwords), which imho is the real problem (and that’s why I initially mentioned the password manager solution).

Of course any pam method that offers one time passwords is a valid alternative as well. No need to use google’s or any other particular implementation.

30

In that case, I would actually recommend setting up HOTP for one’s account, as that allows you to put a bunch of OTPs on paper, hide that someplace, and use them whenever (rather than requiring a second electronic device with a well-synchronized clock to generate a valid TOTP on demand).

31

This, exactly. I have my password vault - and I have a backup (paper notes) of several important passwords at home, known to the family.

When my brother in law comes back to me 4 years after (when he bought a phone) I set him a Gmail - asks me for his password!!! I laugh in his face. I gave him the password on paper, and told him to keep it safe - but that he can recover it via his phone number. (He also changed his phone and number 3 times in that time).

There comes a stage where you tell people - if you LOCK it and throw away the key, then there comes a point where you have to learn or lose it.

1 Like
32

Nah! I don’t use hard copies. I have just shared my keepasxc file with some friends of mine and they have shared theirs with me, so all of us know that there are several copies of our keepassxc passwords. The password I used to encrypt that file is a sentence describing a fact about myself only known to me (like for example “when I was 9 years old I had a crush with my school teacher who’s name was…”), total 544 bits of entropy, and the only possibility to forget it is if I suffer from memory loss :stuck_out_tongue:

PS: This is not my actual password, but I guess you get it

33

Also using your personal grammar for good measure, I see. :stuck_out_tongue:

In the meantime, I’ve come to the realization that even if SDDM (and kscreenlocker) were to support OTPs out of the box already (it seems that they don’t, unlike GDM, xlockscreen, the equivalents of several other Display Managers, and the relevant CLI tools like login(1)), as long as there’s no disk encryption involved, the standard Linux password recovery procedure:

  1. Boot computer from installation / rescue media
  2. Mount hard disk’s root FS (if the rescue system didn’t already do that automagically)
  3. Edit the /etc/shadow thereon directly and set a new or empty password
  4. Reboot from disk
  5. Log in with empty/new password (and, if empty, set a real new one)

and this one I just thought up:

  1. Create another user account with a nonobvious name
  2. (Optionally try to keep SDDM from displaying it as an account you can pick to log in as)
  3. Make sure that that user can sudo (and thus change other users’ passwords)
  4. Write name and password on a post-it and hide it
  5. Come the dreadful day, grab the post-it and use it

and its further-simplified variant:

  1. Set a password for root and put that on a hidden post-it, instead of relying only on sudo

are more generally applicable and still simpler solutions to the problem at hand …

34

This is not my password in any case. My password is actually in Greek :stuck_out_tongue:

35

Thank you guys for the otp suggestions, but OTP it’s a 2FA, so, the first factor it’s the password, if the user doesn’t remember it , OTP it’s completely useless.

Beside setting an OTP it’s not very user friendly, it is not intended to restore forgotten passwords, but to enforce the security, as you need to know the credentials AND have a physical token generator.

That brainstorming ideas relies on the ability for a home user, without an IT administrator, and not being a tech savvy, to reset his password in a easy and graphical way.

I, as a 30 year experienced Linux administrator, I do know how to recover a password, reinforce security, or use other authentication methods, but stay focused in the conversation, please. We’re not talking about us, experienced Linux user which a reset password feature is completely useless because, for a start, we will never forget our password.

The idea is the ability we can have to empathize with those users who can find themselves in that situation, and not mocking them with sentences like “use a livecd method”, “you should have written it down in a paper/password manager”, “take the computer to a professional, and he will reset it for you”.

The idea, again, would be to let a user RESET THE FORGOTTEN PASSWORD", nothing more, nothing else.

36

Actually, no, if you read the Arch HowTo I posted a link to, it tells you how to configure PAM so that it’ll accept either OTP or password (or any other supported auth method you have a PAM module for) alone. sufficient vs. required in the PAM configs.

Well then, if I may rephrase your request as it stands now:

  • The user is likely to forget the password (“something you know”) he uses on a daily(?) basis
  • I.e., forget about having him memorize anything else (root password)
  • No dice on “something you have” (separate from the computer itself, like a root password on a well-hidden post-it), either

That IMHO leaves the options of “something you are” (does the computer have a fingerprint reader?) and “physical access to the computer” (login without a password, or something still well below the level of a password, like … uh … having a password prompt that says Type "pAssword" here: … ?).

Using “security questions” in a way that has the answers checked like a password, i.e., you have to enter the answer exactly like you registered it, letter by letter by correct number of spaces after that period, would not be significantly different from just another rarely-used password. In order to make that sufficiently non-password-ish, you’d need some AI that accepts the input “I broke my left leg when I tried” as matching the original “attempting that led to having my left leg broken”, but not “attempting that left me broken, having one leg”.

Or, well, you could try to come up with security questions where the answers do not allow such variation. “What year did you …, enter just the four-digit number, do not add a period to end your ‘sentence’”. I’m not sure that that will be significantly more of a hurdle to an intruder than an outright passwordless login, though …

1 Like
37

I won’t consider that to be a good idea at all for FDO.

On the other hand, it’s not really required.

Since SDDM themes can run arbitrary code, just make an alternate user developed theme that will ask the questions and call passwd.

Note that I don’t recommend using security questions this way, but the technical part is doable.

1 Like
38

I think there’s too much discussion of technical possibilities in this thread and not enough focus on the why and the user experience. The implementation needs to fit the use case; if there’s a real problem to solve here, we can build whatever we need to solve it.

2 Likes
39

… say, since GUI-laden rescue systems on a USB stick that autodetect and -mount nonencrypted Linux FSes on the HDD are a thing, what would you think about a “boot stick” that happens to sport a “change all plain-user passwords (in /etc/shadow) to empty and shut down” option? Near-zero dependency on the unixoid OS (and its DM), and given a friend who still remembers the password of his machine, you don’t even need to prepare the stick in advance. Sort of a reverse DBAN … :wink:

“Do NOT mix up these two USB sticks!!!” :scream:

40

I think while the conversation can be interesting, it goes offtopic again and again.

Regarding we can think about OTP, fingerprints reader, autologin feature, liveCD to restore passwords, passwords managers, post-its, and all the stuff we were talking, none of them covers the necessity one user can have in a given time to recover the password. Because it’s like we are talking about what to do when we are in a forest that is on fire, and it seems that the answers are “don’t go to the forest”, “beaches are safer”, “fly a helicopter and get out of there”, “what are you doing not wearing fireproof suit, for god’ sake???”…

Because the thread is about that, about what happens when a home user has forgotten the password, and needs to reset it. Currently, the only option is not user-friendly at all, and perhaps, if that user does not have another computer to burn the USB, perhaps is not possible to carry out, that if the tech skill level is high enough to do the password reset via liveCD.

1 Like