The authentication problem

The problem of authentication has many aspects, and one has to distinguish them clearly, or one risks to open one-self to structural vulnerabilities which are independent of the quality and solidity of the authentication protocol used.  Generally, the authentication problem consists in an entity obtaining convincing proof of the identity of another entity with which it is communicating, or obtaining a convincing proof of being a member of an identified group from the other entity.

One should distinguish different possibilities:

  1. The nature of the entity that has to be convinced:
    1. Is it a physical person ?
    2. Is it an administrative organisation (a moral entity) ?
    3. Is it a piece of software ?
    4. Is it a physical device ?
  2. The nature of the entity that has to convince the other entity:
    1. Is it a physical person ?
    2. Is it an administrative organisation (a moral entity) ?
    3. Is it a piece of software ?
    4. Is it a physical device ?
  3. The kind of identity that has to be verified:
    1. Is it the identity of a physical person ?
    2. Is it a virtual identity (an "avatar") ?
    3. Is it a DNS name ?
    4. Is it an e-mail address ?  A phone number ?  A postal address ?
    5. Is it a membership of a group, club .... ?

One rarely considers these kinds of questions, because in daily real life, there's essentially only one single authentication problem to solve: the recognition of another human being in its physical presence.  We're dealing with Joe, period.  Joe, that's at the same time Joe the employee, Joe the man, Joe the customer, Joe the husband, Joe the father, Joe the owner, Joe the American citizen,...  When one recognizes Joe's face, his voice and so on, we are convinced we're dealing with the Joe we know.  However, in the computer world, Joe can have 10 facebook accounts, where he has different friends.  Joe can have 5 e-mail accounts and 3 phone numbers.  If one votes, will Joe vote, or will each of his facebook accounts vote ?  If Joe has lost one of his phones that have access to his facebook acounts and e-mail accounts, are we dealing with Joe, or with someone else abusing from this access ?

If we entered in contact with "someone" on a discussion forum, and we want to exchange more with that "person", how do we do ?  All we know of this "person" is an avatar on a forum.  How do we do to give him/her/it access to another web site ?  Does there need to be a physical identity for that ?

When we contact an e-business website on the internet, and we want to place an order, there's not a "person" on the other side.  Being able to verify a physical identity of the employee that is handling your order (you don't know the employees of that company, that may reside on the other side of the globe) will not help you in anything.  You want to know whether the web site, the banc account and the e-mail address correspond to the entity of which you got to know its existence in one way or another (Google ?  Publicity in your physical mailbox ?  Spam in your e-mail box ?) and with which you decided to enter into commercial contact.  Maybe you want to know what moral entity it corresponds to and in what jurisdiction if you need to sue it for scamming you.

When you use a cloud service such as Dropbox or Mega, these services want to know if you are the same entity as last time, but these services don't care whether you are a person, a company, a device or a computer program.  They just want you to be the same entity when you withdraw files than when you deposited files.

On the other hand, if you want to contact the web site of, say, Apple, you want to be sure that the site you contact, is the site of that company, known from the publicities, newspapers, stock market, news broadcasts on TV (even if you don't know "personally" this company) and Apple-stores.  Even if the site is called, you don't want to connect to a site where the owner is a relatively unknown individual that lives in Ivory Coast.

These examples try to illustrate that for each authentication problem, one needs to ask oneself these questions before being able to put in place an authentication system that makes sense.  Very often, one uses proxies for authentication, and one needs to be very careful in doing so.  By proxy, we mean a substitute for the entity we really want to authenticate by an entity that is easier to authenticate.  For instance, a use case may need to authenticate a physical person, but it will, in reality authenticate a phone number.  The phone number is in that case, the proxy of the physical person.  One needs to realize that every physical person that has really access to the phone number, will be a legitimate entity ; no matter how robust the authentication procedure, it will be satisfied, because the authenticated entity (the phone number) is the right entity.

One needs to distinguish two cases:

  1. the two entities are physical entities and are in physical proximity
  2. all other cases

Effectively, the first case contains the classical human authentication: the two entities are people, and they are in physical proximity: one recognises the other person visually and otherwise as the right person.  It is quite difficult to make this authentication fail if the two people know one-another well.  Often, we project an authentication procedure on this case.

We can enlarge this first case to the authentication when one of the entities is not a person, but a physical device.  In that case, the device has to recognize the physical person and it can apply some sophisticated biometry: fingerprint, iris, face .... recognition.  This kind of authentication, which is an imitation of the standard human authentication, only makes sense if the device that needs to be convinced is in physical proximity of the human to be authenticated.  Any device at a distance needs to receive the biometric information ; that information is then nothing else but a "secret key" of which the secret is hard to keep, because the carrier is your body !  At a distance, one cannot distinguish a device that does a real biometric measurement from a device that just sends you the file with those informations in it.

All the other cases have to do with the exchange of information that needs to convince one entity that the other entity is the right one.  We are not used to this in everyday life, except in one case: a telephone call, where we try to recognize other people's voice.  We all know the jokes that have been played onto well-known people (like politicians) that way.

Finally, in the limited frame of cyber-security, one needs to realize that the only forms of authentication that we can consider, are correlations between contacts with entities.  We cannot identify entities in an absolute way, and for almost all application cases, that is not needed.  In other words: the use cases of authentication that we consider, are essentially of the kind: "the entity with which I'm in contact right now, is the same entity with which I was in contact in the past." regardless of what exactly it was.  There is however, another authentication problem, which is much harder to solve: "the entity I'm in contact with right now, is a different entity than the entity I contacted in the past".  This problem is way, way trickier but it matters in cases of vote, distribution, opinion....

The reason why the correlation (or in hard and rare cases, the non-correlation) is the basis of the authentication problem is that our interactions with other entities are, most of the time, independent of their absolute identity.  In a commercial relationship, if the customer calls himself systematically "Joe" even though in reality his real identity is Jack, but pays us, buys an article, gives us an address to send the goods etc... under the same name "Joe", we don't have a problem.  We receive "Joe's" money, we get the order placed by "Joe", we send it to "Joe's" address, we write a bill for "Joe" and that's it.  If a new employee of a company calls himself "Joe" since the first day on the job, there's no problem that we make a computer account for that "Joe" and give him access to the systems he needs to access for his job under the name of "Joe".  Even though he might be "Jack" in reality.  We don't really care, from the point of view of cyber security.  It is only in relationship with legal entities, like court and law, that Jack may have a problem but for cyber security, we don't care.

This point becomes even more evident when we consider anonymous entities.  One could ask oneself whether it even makes sense to talk about the authentication of anonymous entities, but it is exactly there that one sees that what matters, is the correlation between contacts.  Anonymous entities make one often think about illegal or criminal activities, like drugs markets or weapon markets on the dark net, but there are many legitimate applications of anonymous entities.  Grading exams or job applications, in order to avoid any form of favouritism or discrimination but the officially announced selection rules, is such an example.  Psychological aid to people with depressions, suicide idea, or the like, can be another one: even though the caller is anonymous, if there are multiple sessions, one needs to know one has to do with the same entity as last time because confidential information may be passed.  The sales of erotic articles usually has anonymous buyers, but there still needs to be a correlation between the entity ordering, the entity paying, the entity obtaining the article and eventually, the entity obtaining after-sales services.  In all these applications, one wants to avoid to have to identify the entity in an absolute way, anonymity obliges, but one still needs the authentication of correlations.

As such, in relative authentication, we have two steps:

  1. the (first) taking of identity
  2. the (subsequent) proof of identity

During the first phase, the new entity gives, or receives its "identifiers", that is, the elements that will be used to prove/verify its identity.  In the second phase, these identifiers are verified.  As such, the verification of identity establishes a correlation between the first phase and all subsequent phases.  The first phase is vulnerable to a man-in-the-middle attack when it has to be done at a distance. 

Identifying a physical person in physical presence

Although we stressed that the authentication problem isn't limited to physical persons, nevertheless, one needs to recognize that in many cases, the use case is nevertheless, the authentication of a physical person.  As we are interested in relative authentication, the question our use case needs to resolve is: "is the person I'm in contact with right now, the same person that we identified as X in the past ?"

As we've mentioned already, the authentication of a human being by another human being is with us since ages: a human recognizes another one easily, by his looks, his voice, his way of doing things and behaving in general... and this recognition works almost without failure.  We stressed however, that in order for this to work, the two entities need to be humans in physical proximity.  It can seem strange, but this human-human recognition remains extremely important in cyber security: the rooms containing sensitive material (server room...) can be kept by human guardians, who only allow access to people they know.  The "first taking of identity" is then a chain of trust for the guardians, of which the trust anchor has been established when they got on the job and one has shown them who was the boss of the company, who was the head of the computer department and so on.  As a last recourse, they can always go and ask the boss whether this person they don't know, can have access to the server room or not.  One shouldn't neglect this physical protection with physical barriers, that only allow access by human guardians: relatively few computing devices resist tampering when one has physical access to them.  Machines in a server room are not designed to resist physical intrusion while they are functioning (they might be cryptographically protected when switched off however).

When, however, the entity that needs to be convinced is a technical entity (a device, a piece of software.... of the identity of a human, the only form of authentication that imitates the human recognition is biometry, by a device that can have trust in the integrity of the physical sensors that will apply the biometric measurements on the body of the human to be recognized.   One needs to pay attention to the fact that the biometric sensors need to be sufficiently sophisticated not to be misguided by poor imitations like pictures.  Apart from direct biometry, all other methods of authentication of a person don't need its physical presence, because it has to do with information transmission, and not with human body recognition.  Of course, one can require that the information is transmitted locally (say on a local terminal) but that has nothing to do with it: this information doesn't guarantee the presence of the right human body.  Nevertheless, the requirement of local transmission of authentication information can be a good thing, because it is a supplementary security measure that limits the number of people that can do so.  For very sensitive operations, it can be indeed a good idea to only allow local authentication, if the price to pay, that is, not being able to do said operations at a distance, is acceptable.

Authentication at a distance: generalities

In all cases distinct from the previous case (physical presence of a physical person), all forms of authentication are based upon the transmission of information that only the to be identified entity can produce and which the to be convinced entity can verify.  As such, it should be already evident that in principle, one cannot authenticate directly a physical person at a distance, because the sole way to do so, is by authenticate his body (through biometry).  Hence, the use of one or several proxies that replace the identity of the physical person, is unavoidable.  These proxies fall in different categories:

  1. the knowledge or access to knowledge of a secret (a key, a password...) that allows the production of the information to be transmitted
  2. the physical control over a device (a phone, a dongle...) that can be the source of information
  3. another authentication that allows one to access the needed information (a Facebook account, an e-mail account....)

Every proxy is called a "factor", and for more security, one can use an authentication procedure that uses several factors.  One needs to convince the entity of the authentication of different proxies simultaneously: one knows a password, one can read an SMS, one can read a confirmation e-mail....  However, very often, these different factors are an illusion, because they are correlated.  In that case, this multi-factor authentication only provides a false sense of security.

One needs to realise that an authentication at a distance will identify one or several other entities, different from a physical person, and that the authentication procedure will succeed if these entities are the right ones, which is independent of the question whether the right person controls these entities.  if the authentication is based upon the possession of a telephone, then the right telephone in the wrong hands will give access, and one cannot blame the authentication procedure of having failed: it is the right telephone !

If there's one thing to take home from the authentication problem, it is this: one needs to distinguish the solidity of the authentication of entities from the pertinence of the choice of the proxies.  A solid authentication procedure will make sure that the proxies are the right ones ; but only the pertinence of the choice of the proxies will make sure that these proxies correspond to the right entity (a physical person for instance) one wanted really to identify.

 One can compare this to the distinction between the quality of a lock, and the question of whether the right person has the key.  A good quality lock will only open if one presents the right key.  A bad quality lock will also open with a screw driver.  But one cannot blame the lock to open with the right key if this right key is in the hands of the wrong person.  If you have bought a lock of very high quality, but you leave the key under the door mat, your proxy strategy is wrong, but that's not the lock's fault.

As such, a golden rule is: as authentication at a distance is always more fragile than local physical authentication, because distance authentication must always make use of proxies, only open up authentication at a distance for what is really needed, and keep, if possible, for very sensitive things, all authentication local where the "guardian" effect matters.

As such, it can be useful to reduce user permissions when employees work remotely, especially if these are users with a lot of privileges, at least in as much as it is possible and doesn't interfere with the job to be done.  If a user has administration rights, it can be a good choice to only let him have his administration rights locally but not at a distance.  As such, this user can work normally at a distance, but can only install new software and do the maintenance of his account when at the office.

Certain authentication procedures can be done without an encrypted link, but it is nevertheless preferable to use an encrypted link of which one can make sure that only the two identified parties have the right key.  This is of course evident for every interaction after identification because otherwise, a Man in the Middle attack is possible.  If you authenticate on a clear link with the right authentication procedure on a server which gives you the right to send commands to the server, an attacker can substitute himself to you to give the instructions to the server he wants if this link is not encrypted.  The use cases where one authenticates without any further interaction are rare.  The encryption of the link is keeping the link confidential, but more importantly, it makes the communication unalterable.

As we've seen, authentication consists of two aspects: a first "taking of identity", followed by one or more verification of identity.  Taking an identity at a distance is even more tricky than verifying an identity at a distance that was taken locally and in physical presence.  One should always, if possible, prefer the first taking of an identity in local physical presence.  This is especially true for company personnel.

In the case of a first contact at a distance, there is, however, no alternative to taking an identity at a distance.  This is the case for all "cloud" and "account" type of services.  In that case, one has to understand the potential fragility of this identity, especially if one could have been the victim of a man in the middle attack.


A classical way of proving you're the same entity as when you got your identity consists in agreeing over a common secret during the initial identification, and to send the agreed-over secret when one wants to prove one's identity.  If that secret can be memorised by a human being moreover, at first sight, we aren't even needing a proxy: the sole entity that is able to produce the secret information, is the human being knowing this secret by heart.  This is why the password is still a tool that is often used to identify a human at a distance.

However, the drawbacks of a password are nevertheless numerous:

  1. a human being has a hard time remembering several passwords with a large entropy.  This renders the technique intrinsically vulnerable.
  2. a password must be typed in, sent and given in clear to an apparatus that could copy it and store it.
  3. a password can easily be given to another entity (a script, another person....).  As such, the password is a proxy after all: the "entity that knows the password" isn't necessarily a human being (this in contrast to a biometric measurement that cannot be passed by a script, or another human being).
  4. the entity that needs to be convinced, can just as well pretend to be you because it receives the password in the clear.

These inconveniences make that using passwords should be avoided as the sole means of authentication ; on the other hand, the password is, together with biometric identification, the sole way for a human being to make himself known to a local apparatus (his portable computer, his mobile phone....).

Given that a password is "fragile" because it is a secret, the entity that needs to verify the password better stores only a hash of the password and not the password in the clear.  As such, the entity can verify the password (it calculates the hash of the received password and verifies if it corresponds to the stored hash of it) without the need of needing the password in the clear.  This has the advantage that if the verifying entity itself gets compromised, at least, it doesn't give away the passwords, because it doesn't know them.

Symmetric key

In a certain way, a symmetric key agreed upon during first identification is the same as a password: we share a secret during initial identification, and that secret will be used during the following proofs of identity.   But, contrary to a password, the symmetric key is often too complicated to be remembered by a human being, and one doesn't send the symmetric key directly as a proof of knowledge.

A symmetric key is used during a dialogue to prove to both entities that they are the right ones (that the other entity knows the key too).  Entity 1 proves to entity 2 that he knows the key, and entity 2 proves to entity 1 that he knows the key, without any one being able to learn the key in the process, if he didn't know it (if he wasn't the right entity).  The dialogue goes like this, where we call S the symmetric key the two entities are supposed to know:

  1. entity 1 chooses a random number R1 and sends it to entity 2
  2. entity 2 chooses a random number R2 different from R1, and sends it to entity 1
  3. entity 2 calculates: P1 = hash(S + R1) and P2 = hash(S + R2)
  4. entity 1 calculates P1' = hash(S + R1) and P2' = hash(S + R2)
  5. entity 2 sends P1 to entity 1
  6. entity 1 sends P2' to entity 2
  7. entity 1 compares P1 received with P1': if it agrees, then entity 2 knows S
  8. entity 2 compares P2' received with P2: if it agrees, then entity 1 knows S

As such, entity 1 has proven to entity 2 that he knows S, and vice versa.   Compared to the password, the symmetric key has the following advantages:

  1. the key can contain much more entropy
  2. the communication doesn't need to be confidential, there is no knowledge to be stolen from it
  3. if ever we connected to the wrong entity, we didn't give away our secret
  4. the two entities can be convinced that they talk to the right partner

The big disadvantage of the symmetric key as compared to the password is however, that the key cannot be learned by heart by a human.  The human can also not do the operations needed.  As such, one can only identify a proxy: the device, or software, that contains the key.

The symmetric key and the password are equivalent for the property that one of the entities can give the key to a third entity that can then mimick to be entity 1 or 2.  This time, it is necessary that both entities keep the key S in the clear, and cannot satisfy themselves with storing just a hash or something.  As such, when entity 1 gets compromised, the key can be stolen.

A potential problem with a symmetric key is that one has to give/install this key on every technical entity one will use to authenticate oneself.  If one uses a portable computer, a mobile phone, two desktop computers etc... it looks like one needs to install the symmetric key on all these devices at a certain moment, if one wants to use these devices to authenticate.  This can become problematic because it means that all these entities have the capacity to authenticate as "you": they all become valid proxies because they all know the key, and "device that knows the key" was the proxy used.  In fact, this is not in any way different from typing your password on these devices.  Indeed, these devices might just as well record your password if you type it on them, which comes down to the same.  However, one usually considers that normally, a device on which you type a password isn't supposed to register it, while the key needs to be registered on disk.  However, this only illustrates an illusion you may have: that when you type your password, it will not be recorded.  If you hesitate to install a symmetric key on a machine because it might be compromised, then you should wonder whether it is a good idea to type your password on said machine !  What seemed to be a vulnerability of the key (having to install it on a potentially compromised machine) may in fact just be a reality check of a risk you might have ignored when typing your password on the same machine.

As such, the symmetric key allows one to use in fact non-secure machines to authenticate without a risk: you can keep your key on a secure device.  You only really need to transfer the values of R1, R2, P1 and P2 from the insecure machine to your secure machine or vice versa (using, say, a QR code).  The insecure machine is then just part of the communication infrastructure, and the communication doesn't need to be confidential.  One could use a specific device as secure device, of which it is hard to extract the symmetric key itself, but which can easily interact concerning the values of R1, R2, P1 and P2.  By locking the key into such a specific device, one can obtain that the key will most probably not be transmitted.  As such, the proxy becomes "he/she who controls the small secure device".

One time password

The one time password is a simplification of the usage of a symmetric key.  It is a technique that is often used in combination with a small device (or an imitation on a mobile phone, like Google Authenticator).  There remains to have convened a secret key upon first identification.  This time, the proof of identity doesn't go in both ways.  Entity 2 wants simply to convince entity 1 of its identity, but entity 1 doesn't try to convince entity 2.  The protocol goes like this:

  1. entity 1 sends a challenge (a number) to entity 2: value R1
  2. entity 1 calculates P1 = hash(S + R1)
  3. entity 2 calculates P1' = hash(S + R1)
  4. entity 2 sends P1' to entity 1
  5. entity 1 verifies  whether the received P1' corresponds to P1.  If it is, entity 1 knows that entity 2 knows the key

Certain banking applications use this system: you install an application on your mobile phone, or you get a small device from your bank, which contains key S.  When you connect to their web site, they demand you to type a given number (which is displayed on their site) on your mobile application or into your device.  If you do so, this application or that device will calculate another number, that you are supposed to type as an answer on their site.  If this succeeds, the bank is convinced it is talking to you.  This is called sometimes: a password for to be used once.

One can even simplify this scheme somewhat further, where the challenge is replaced by:

  1. the current time (usually in "units" of 30 seconds)
  2. a counter

 As such, one doesn't even need to receive a challenge from entity 1.  At every moment, entity 1 and entity 2 can know what is the number T of times that 30 seconds have passed since January 1. 1970 at midnight.   This number T replaces R1 in the challenge.  During 30 seconds, the "password" thus calculated by P1 = hash(S + T) remains valid.  Instead of using the time, one can simply use a counter that counts the number of successful authentications.  Let us call this number N.  The first time you will identify, N = 0 and you will need to use the password hash(S + 0).  Next time, you will need to use the password hash(S+1).  After that, you'll need to use hash(S+2).  Etc....  The nice thing of this solution is that it avoids the 30 second time lapse of vulnerability during the "time" method ; even though one can easily protect oneself against this vulnerability, by not allowing for more than 1 authentication attempt during 30 seconds.  These two techniques are the ones used by Google Authenticator.

Asymmetric key

Every entity generates a key pair: a public key and a private key, and will always keep secret the private key.  During a first identification, the entity that needs to be convinced receives the public key from the entity that needs to convince.  This can be done in both ways, but strictly speaking, it is only necessary that the unit that needs to be convinced is in possession of the public key and has the certainty that this public key does correspond to the entity that needs to identify later.  The only thing needed is that the entity to be convinced has the public key of the entity that needs to convince, and that the entity to be convinced has the certainty that it has the key of the right entity.  One has to make absolutely sure that during first identification, the channel over which the public key is transmitted, is not victim to a man in the middle attack, but this is true for any kind of first relative identification.  Afterwards, the entity that wants to convince can do this easily by signing with its private key, any piece of data sent to the entity to be convinced.

The advantage of the asymmetric key over the symmetric key is that one can use the same key pair (public/private) to identify with different entities: the to be convinced unity, having only your public key, cannot mimic as you.  In the case of only one entity to be convinced, this doesn't play any role: if you share a symmetric key with just one other entity, this entity can mimic you... only with respect to you.  But if you share the same symmetric key with tens of entities, each of these entities can mimic you with respect to another entity.  If you want to avoid that when using symmetric keys, you'd need a different symmetric key with each of these entities.  Strictly speaking, a symmetric key should only be used between two entities, not more.  This is not the case with an asymmetric key, and its most important advantage.   All entities holding your public key can check your identity, but none of them can mimic you: the proof can only be provided by the holder of the private key, which you share with nobody.

The authentication is done this way in the SSH protocol.  This technique is especially adapted to the case where the entities that need to convince, are devices or pieces of software, and not humans.  For instance, computer A has its backup done by computer B.  It is necessary that the backup process running on computer A can authenticate as "backup process of computer A" on computer B.  One can generate a key pair on computer A, of which one gives the public key to computer B, indicating it is the key of "backup process on computer A".  One gives read access to the private key registered in the file system on A, to the backup process running there.  When the backup process wants to send backup data to B (or retrieve backup data from B), this process can authenticate with computer B as being "backup process on computer A".  Any challenge sent by B can be resolved by this process, because it has access to the private key, and B can verify the response using the public key.   The cloud service "github" works that way.  One can install a public key on a project on github.  The local "git" client needs to access the local private key on your computer to automatically backup new versions on that project on github.   If one needs to access the same project from different computers, then one can install different public keys corresponding to the different machines on the project ; this avoids having to transport the private key from one computer to the other: each computer has his own key pair.  Here we see that the entity that is authenticated is "a computer", and not "a human" or an "account owner".  if, as a single user, you work on 10 different computers, you install 10 different public keys of the 10 different machines having each their key pair.   Your github project then knows 10 different entities that have access to the project.

The use of authentication of a machine, before authenticating a user (a person) can be a tactic to increase security.  In the frame of a company where employees identify at a distance, one can ask them to authenticate those devices they would like to use at a distance (for instance, their portable computer, their mobile phone, ....) with a system like SSH.  The public keys of those devices are then recorded on the company servers, allowing them to set up a connection, before even they authenticate the employee.  As such, the potential authentication has to be done by one of those devices, before even the employee can authenticate himself.  This is an extra layer of security because an attacker cannot even establish a link from a device that doesn't have one of those private keys.

The comeback of the password

In as much as the classical password authentication is a rather insecure technique, the advantage of the password, remembered by a human being, is nevertheless something that other authentication systems at a distance don't have: the need for the human to give his password.  The two big problems with password authentication were that a password remembered by a human:

  • has low entropy
  • cannot do operations on it, the human can just reproduce it

but one has constructed systems where one combines the advantage of the human-remembered password (so, in principle not registered by a proxy) with the advantages of key-based systems (much more entropy, possibility to do cryptographic operations).  There are relatively sophisticated cryptographic protocols that combine passwords and keys, where the low entropy of the password is maximally protected (by reducing the brute force attack on it to at best one attempt per authentication dialogue).

A simple way to combine passwords and keys, is by encrypting the key with the password on a secure device.  In as much as the device is secure, it will never stock the password, but will only use it "on the fly" to decrypt the key in memory, only keeping the decrypted key in memory and forgetting the password immediately after decryption of the key.  The password is hence never registered, and is even only present in memory, the time to decrypt the key.  The decrypted key remains in memory as long as the session lasts, but is never permanently registered.  Of course, one has to have faith in the correct working of this device, but if this works correctly, the key is unusable without the human-remembered password.  The proxy is hence the device, but this only becomes a proxy, when the human has given it the password.  Even if the password entropy is low, an attacker laying his hands on the device, or on the recorded encrypted key on the device, can only make one password guess at a time, obtaining maybe the right decrypted key, maybe a wrong decrypted key.  In order to find out, he has to use the trial of decrypted key in an authentication dialogue.  He cannot crack the key offline with brute force: he doesn't know which of the decryption trials is the correct one.  Of course, in as much as the device is insecure, and can be compromised, all this is moot, because then the device can record the password.

An imitation of this behaviour is done with password managers such as lastpass, or the password manager in Firefox.  It is only an imitation, because it is not used on a separate, secure device, but on your local computer.


In the frame of managing cyber-security, the authentication question is primordial and one needs to analyse the situation on a case by case basis, in order to pick the best authentication policy adapted to the user needs and taking into account the potential risks.  In as much as it is possible, one should use existing standards, but there exist many more possibilities than the usual password.  The careful choice of the right authentication policy is one of the cornerstones of the management of the security risk.  One can even say that without a good authentication policy, all the rest of cyber security actions are moot.