It is generally accepted that password change mechanisms should ask the user for
ID: 662032 • Letter: I
Question
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?
Explanation / Answer
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.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.