It is generally accepted that password change mechanisms should ask the user for their old password (e.g. OWASP) The reason being that an attacker who has temporary access to a user's session (be it through XSS, computer left logged-in, whatever) would only have access to that session.

Presumably this principle should carry forward to other authentication mechanisms - certificates, tokens, etc. (although I've never seen this discussed)

However, consider how SSH authorized_keys works. If you have access to a user's login session, but not their keys (e.g. they left their computer logged-in) then you can modify the authorized_keys file. You could add your own key to the file, so you could get access to the account in future. You could also remove the legitimate keys to lock out the account owner.

So should the SSH designers be looking at ways of tightening this? And what approaches could we take to stop this vulnerability?

  • 1
    If you have access to a user’s session, that user is toast. Modify .bashrc or equivalent to grab passwords, etc..
    – Ry-
    Jun 6, 2014 at 16:23
  • @minitech - that's a good point! Still, the Unix passwd program forces you to re-enter your password, which seems pretty pointless given .bashrc and stuff. And it's the same deal on Windows.
    – paj28
    Jun 6, 2014 at 16:39

1 Answer 1


Yes, you're correct, SSH authorized_keys allow authentication changes without verification if an opponent is granted (or steals) shell access once (or has sufficient file access).

I'm going to go out on a limb here and suggest that SSH authorized_keys was designed as an improvement upon the .rhosts paradigm. A way to allow seamless access between hosts but with more than bare trust. So from that perspective, authorized_keys are indeed a great improvement in security. That's not to excuse the issue you're describing, but to put it in context.

The only approach that will really address this issue is to centralize key authentication. Instead of using disparate key files, require users to submit keys into a system repository, just as they submit their passwords into the /etc/shadow repository via intermediary programs. That'll mean code, and file ownership and protection issues, and the replacement of a simple file edit control with a more structured and probably difficult database manipulation interface (one that requires authentication to permit manipulation!).

Doable? Certainly. Easy? No, it'll be a bit of work. Likely? Probably not; this area of weakness has been known and accepted for a long time, without new impetus I don't see anyone pushing hard to fix it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .