I can understand that typing my user name on the computer is "identification" and providing the password is "authentication" but when I use a smart card or a key fob I see no identification taking place?

  • It's not you that's being identified, it's the fob that's being identified ... – schroeder Aug 12 '14 at 0:09

The smart card, key fob does both identification and authentication. I guess he mean "key fob" as in those EM4102 fobs you scan to open a physical door at a Corporation.

Those fobs do contain a unique number, which acts both as your username and password. Compare it with a "password only" login, where the entered password BOTH tell who you are and authenticates you, thus theres multiple valid passwords.

The fobs itself does not contain any identification that is tied to you, rather, the fob is a pointer to a field in a database in the authentication server. Like a employee ID.

A better comparision is a alarm panel. A alarm panel can have multiple PINs to accomodate multiple users. In this case, the code entered will be used as both identification and authorization, so for example, I might have a code "1234" which correspond to user "Anyone Anyonesson" and a code "7622" which correspond to a user "Another Anothersson". When 7622 is entered, it will be written to the authorization log that "Another Anothersson turned off the alarm."

Smart cards also contain a algoritm to authenticate the card. Theres also "key fobs" that work like smart cards (MIFARE) that can be authenticated by the reader. The authentication is in many cases same for all cards/keyfobs, eg the authentication does only assert that the card/keyfob is genuinely issued and is not a duplicate of a Another keyfob/smart card.

If you use such a "smart card" or "smart keyfob", it can be compared with a system that use a username to identify you and a secret "group" password which is equal for ALL users, to authenticate you.


This really depends on the system. Simple key fobs don't do identification -- your identity is simply "someone who is authorized to open the door". More sophisticated systems will have your identity programmed into the card or fob, so that both identity and authentication are established during the unlocking process.

  • If the fob has a number that is recorded somewhere as being issued to you, then strictly speaking it DOES identify you. This is true in most cases. Thus the door entry system could log your number and the datetime as a record that YOU entered the door. There are normally admin procedures around reporting lost or stolen cards to mitigate the risk that it is NOT you that opened that door. – DodgyG33za Sep 4 '14 at 2:35

Using simple key to open your room door is a case when authorization happens before and instead of identification and authentication, though it should be the other way around. I would say that in this case the term "identification" does not apply.

A smart card however can provide an analogue of your name and password to the system, both "authentication" and "identification", you just don't notice this. That's the point of user convenience. You can read how a smart card based solution works here http://www.wwpass.com/sites/default/files/WWPass_WhitePaper-HowItWorks.pdf There is a good analogy with safe deposit box that lets you grasp the concept quickly.


An identity is any subset of attributes of an individual which uniquely characterizes this individual within any set of individuals. http://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.18.pdf

Often, when you are going through an authentication process, you or a device (that act on your behalf) often provides a pseudonym (identifier, but not necessary an identity).

Examples of such pseudonyms:

  • Username. E.g., "abc123". It uniquely identifies the row in a database where the corresponding password is stored. However, it does not necessary provide any information about your identity.
  • Public key of an asymmetric key pair.
  • ...

There are four entities:

  1. User identity (e.g., "Mr ... living in ... date of birth ...")
  2. User pseudonym ("abc123")
  3. Authentication mechanism (e.g., a challenge response protocol)
  4. Authorization mechanism (e.g., if authentication is successful, then open the car doors)

Some applications require 2, 3 and 4. In the case of the key fob for a car, the user here is your key fob. Actually, there is no link between you and your key fob in this case. To make the link, some tokens. e.g., supports authentication based on a PIN (that should be known only to you). The token will authenticate itself to the car only if you authenticate yourself to the token.

Some applications require 2, 3, 4 and give you a possibility to add information about your identity if you wish to (such as stackexchange).

Some applications require all 1, 2, 3 and 4. Before they resister a user they verify the identity and link it to your pseudonym (e.g., a banking application).

The pseudonym (ID) can be provided by a user explicitly (e.g., by entering the username) or the identification process on server side (e.g., a user provides the fingerprint but no ID, the application goes through the db of all fingerprints and identifies the record with a fingerprint that fits the best and the match is higher than X%). In the latter case, your pseudonym (ID) is implicit and it can be, e.g., a db row number that stores the corresponding fingerprint.


Key fobs, as you put it are identification, just a primitive form of it.

Take a simple key for instance. By taking this key (your username/password) and putting it into the lock (the login interface) one verifies that he, the owner, has the authentication to bypass the lock.

The key acts as a very low level form of identification. Ownership of the key identifies that you are a valid user of the lock.

A key fob/smartcard works the same way. You are authorized to own such key fob/smart card (user), and the key fob/smartcard has the sufficient function to allow you access to an area.

Hope this helped.


Looking at this from the trust angle:

In a corporate environment your username/password combination was issued to you by an authorised officer or administrator who personally identified you and provided you with a secret key (the password). This is something you know (one of the three factors of authentication as indicated in other answers) and it gives you access to certain parts of the corporate network as defined by your permissions (your authorisations) held on an LDAP server on the network.

In that same environment that same authorised officer or administrator follows the same process of identification to give you a card to allow access to parts of the building. In most systems this will be linked to your identity on a control serve somewhere. The card is something you have (another of the three factors of authentication). When using this card to open a door, the reader will contact a control server to decide whether to let you in this particular door (the authorisation).

Both types of credential have their weaknesses. The card can be stolen. The password can be discovered by someone else either via a brute force attack, or because the owner of the password has written it down somewhere.

Note that for secure areas of a facility, most organisations will use a second factor of authentication in addition to the card - either a password or a biometric such as an iris scanner.


There are fundamental differences between authentication, identification. If a login identifies you because it is unique, the same goes for a smartcard or key fob as it has been given to you and you only.

There are different authentication methods :

  • What you know (login/password)
  • What you have (Smartcard / Key fob)
  • What you are (Biometric, fingerprint, eye scanner)

Using only 'wyk' or 'whh' does not certainly prove your identity, this is why in secure environment, it is common to have a two-factor authentication (Two of the three method mentioned above).

To answer your question, a smartcard, or key fob can identify you (It is yours, and is generally linked to a specific account/ID), but its first purpose is to serve as authentication method. If stolen (and not reported), it can still authenticate (the same goes with a stolen login)


Most corporate FOBs communicate to a local server where names are correlated to FOBs with appropriate access. There is obviously an audit trail and it is often sent to an aggregate/syslog server. Your FOB uniquely identifies you, this assumption is based on that you actually are the one using the card. Traditional FOBs have lots of issues, a popular vendor's private key is known, cloning (not brute force) is used to make copies, often you can use your FOB at another corporation using the same vendor, etc. There is usually not challenge mechanism to prove your identity.


That's because there is no identification taking place. At least not between the fob and the reader.

99% of fobs that you'll encounter day-to-day are dumb: they are (oversimplifying) a chip and a coil that carry a couple of numbers – generally, a card ID, and possibly a facility ID (that often times goes unused).

When the fob comes in proximity of a reader, the reader is emitting radio waves a short range. This charges the coil in your fob, and the fob pulses back an encoded signal of that identity. The reader generally is hooked to a database that checks if the credential is activated in the system, and if it is, sends an unlock signal to the lock mechanism (usually a solenoid that is either active (magnetic locks) or passive (physical locks), disabling or enabling respectively to unlock the door.

So, what must the system know about you? Nothing. It only needs to know that the fob itself is authorized. This itself is a form of security, in that, like a physical key, if it's lost it may identify the codes, but won't identify the facility to which it grants access.

  • Like I mentioned in my comment to the OP - it's the fob that is being identified, not the user. The user is attributed to the fob's ID and we can make inferences, but the ID is tied to the fob, not to the user. – schroeder Sep 4 '14 at 15:50
  • Correct. The fob may result in the assumption that it is you accessing the area by the record in the database. For example, Brivo with an HID system ties the ProxKey to a user -- without the user it doesn't operate. But how much information there is on the user is up to the system admin. Again, as you'll notice, I stated that the fob holds 2 pieces of information: ID and Facility number. The assumption is that the person in possession is the assigned user. In this way, it's functionally no different than a key: a coded piece of hardware to check access. – stslavik Sep 5 '14 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.