4 ms·
So an ssh private key is not "something you have" either then? It's certainly not something you know nor something you are. Where does it fit into the MFA sche
by nemoniac 3y ago
So an ssh private key is not "something you have" either then?
It's certainly not something you know nor something you are. Where does it fit into the MFA scheme of things?
- deleted 3y ago[deleted]
- nsheridan 3y agoAn SSH private key isn't "something you have" - it's not a physical object, you can make copies of it. To me it falls into "something you know". You might not be able to type it from memory into a file but in practical terms it's no different to a password, it just usually happens to reside on disk.
- vasco 3y agoIt is something you have, the machine where the file is. It's only something you know if the only way for me to steal it from you is to threaten you to say it. If I can just yank your open laptop from your lap in a cafe, it's something you have.
- charcircuit 3y agoIf you are able to copy it off the laptop it becomes something you know. One important property about something you have is that you the owner of the account have that thing in your possession then no one can hack you. If someone is able to copy it then that invariant is not true. Writing your password on a piece of paper doesn't turn that password into something you have.
- vasco 3y agoIt literally does. Now whoever _has_ that piece of paper can get to your account. A physical piece of paper with a password written on it is no different from a physical key. Unless you're going to say that if you memorise the indentations on your house key then your key is "something you know" too.
- charcircuit 3y agoIf the attacker screenshots the note they can login to your account without HAVING that note. Yes, a house key is something you know.
- mstolpm 3y agoA physical key to your front door is a physical object and something you own - but you can still make copies of it. Someone else can even make a copy from a photo of the key. Google authenticator was (until recently) the only app I know that made it very hard to copy the OAuth secret to another device, lots of other OAuth apps made it a feature to sync/backup your keys. I can't think of a lot of security factors (besides perhaps biometrics) where copying is really impossible. Its just not economic.
- growse 3y agoVery little is "impossible". The point of developing a good second factor is to have a design that makes it economically infeasible to copy. Like a good HSM.
- charcircuit 3y agoA physical key is something you know too if it can be copied. It's just now the thing you know is the bitting of the key.
- saltcured 3y agoThis seems like a pretty significant semantic shift from what multi-factor originally meant. I think the real problem here is that the original idea of factors came from an environment where a person is being authorized for physical access to a controlled facility and the factors are being checked by a trusted deputy of the relying party. The different factors really mean something when you are being checked at a facility gate. What you "know" is held in your mind and up to your will whether to divulge or not. You might not have a choice if put under duress. What you "have" is possessed on your person and you may choose to present it but you may be forced to reveal it in a search. You may have had a choice as to which possessions to carry with you to the facility or which to hide and disavow. What you "are" are passively observable characteristics of yourself that the facility may choose to measure and which may be difficult for an imposter to replicate. You would probably be unable to withhold these characteristics. Once we water this down into a remote access to a website, these factors become vague analogies. In the end, the website is only able to observe information from the local user agent. How much can the website deputize end-user equipment and trust it to make any of these distinctions on its behalf? What you know and what you have start to blur together as different grades of information. There may be no real way for the website to distinguish whether it came from your mind or from some storage or communication device in your possession. What you are and what you have start to blur together as well. There may be no way for the website to distinguish how you protected your possessions (i.e. via biometrics or PIN), or whether you involved other parties who helped with this.
- creshal 3y agoIt's usually considered something you know, since it's used as password replacement (first factor). You can create schemes where it could be considered a second factor (used together with a password, mandatory smartcard/fob storage, etc.), but that's not the regular case. At the same time, it's easy to turn password+TOTP into a single factor by storing both in the same password manager… the theoretical MFA definitions are not the most practical.
- Phemist 3y agoI wrote a 1-page article for this in a small obscure, local-language magazine. The title of which was, translated in English (OMG, I should have also published in English) - Re-factor the factors. I think the 3-factor authentication (3FA) model of "know, have and are" is up for a revision. Knowing that all models are wrong, I hope my suggestion as at least useful. These were really rough thoughts, and I was hoping to spark some discussion of it, but unfortunately that never happened. Anyway, I think the 3FA model has several problems. 1) there is no clear category for recent "ambient" auth factors that are getting very popular, like if one logs into a website on a browser and its fingerprint is unknown, that a "step-up" authentication is required. 2) Authentication is proving that you are who you say you are (you prove an identityclaim), a factor called "are" make the cognitive shortcut of equating the inherence factor to the identity proof very very tempting (and I think many people in the field have fallen for it, given the prevalence of biometrics as sole authentication. 3) Behavioural biometrics like keystroke dynamics do not neatly fall into one of the three categories (it is a little bit of knowledge, it is a little bit of "inherence") I also take major offense to the statement that follows from it, that I AM my fingerprint, or I AM my Iris. NO, I can _prove_ who I am by presenting my fingerprint or iris. To fix this, in the article I suggested moving to a 2-dimensional model of authentication (2DA), that is reminiscent of but not quite the same as the 3FA model. The two dimensions were: Dimension 1: Knowledge vs Possession. A factor is somewhere on this dimension, and my thought was which is which could be tested by the colloquial language use of "know". I can always say I have a password, I have a way of using my phone, but additionally I "know" my password, and I "know" my way of using my phone (even if implicitly). On the otherhand, I have a smartcard, but I do not know it, nor do I know my fingerprint. The SSH private key would in my opinion fall in the "have" part of this dimension. Dimension 2: Transferability. The degree to which the factor is transferable to someone else, to which ownership of the factor can be "bestowed" on someone else. Smartcards are highly transferable, as are passwords, however fingerprints generally are not expected to be transferable, neither are the way I use my phone nor from what browser and what location I log-in. Naturally, 4 relatively distinct quadrants in this space arise, which I tried to label indepently with a single word: possession, high transferability: carry possesion, low transferability: show knowledge, high transfer: tell knowledge, low transfer: do. So, the catchy phrase for the 2DA model would be, things that you "carry, show, tell and do".
- crote 3y agoCorrect, unless you store it solely in a HSM like a Yubikey. One of the critical parts of "something you have" is that it is something only you have. If you can copy it, there is no longer a guarantee that you are the sole person possessing it. This is also why Google Authenticator did not allow export for a very long time. If you want multiple TOTP tokens, you should enroll them separately, so that it is at all times possible to determine which exact token is being used to authenticate and revoke them individually if required.