I'm studying security in computers and in particular the URL Spoofing. I understand that a form of URL spoofing is phishing. Then I read that a countermeasure against phishing is the authentication key. But what is not well hocapito autenticcation key.

On the notes I read:

The key contains a seed related to users, a timer, a secret symmetric key and a counter. There is a timer on the server instead, the same symmetric key is a list of seed -related utilities and also a counter for each user.

When the user clicks the button on the key, it generates an HMAC(Seed||K||Timer||Counter) that is generated on the server in the same way: if there is a match, access is granted.

Clearly, the timer will not be synchronized perfectly, and then the server will generate some codes HMAC with some timer values ​​(depending on the gap between the user and the server timer) and will look for the matching among those.

Each click of the user is recorded by the counter and thus the two are synchronized counter (between server and key). This causes an old code can no longer be used (the counter does not match).

The key does not work if the opponent is particularly noticed and make a session hijacking that is the data you just entered on the phishing site is immediately re-shipped to the actual site of the bank.

It's like a man in the middle, the opponent does an intermediary with its "fake" pages between the bank and the user. It is also for this reason that before carrying out of some significance is often request another password.

The auth-key is a key (consisting of seed, timers, counters and secret symmetric key), which possesses only the client? What is meant by seed? And the counter is related to what? What is a HMAC? How can it be match if the key is secret?

I understood very little. Someone would know explain it in a simple way? Or if there are websites where this subject is treated in a more comprehensive and easy?

I read the Wikipedia page, but I have not found much more.

  • 3
    Can you share the source where you cited that text from? In my understanding this looks more like a CSRF protection, than a phishing protection. Commented May 20, 2014 at 22:27
  • I agree with @Manuel Faux. It appears like it's a token that prevents somebody from generating a url that, for instance, changes your password when clicked from another site Commented Jun 19, 2014 at 23:30
  • This is an algorithm for generating a one-time authentication code like Google Authenticator or hardware tokens are using. The counter is either a real counter (counting keypresses) or is derived from the current time (dividing into number which changes every 10s). The seed+key is burned into that token and must be kept secret. It will never be transmitted for checking but without knowing it you can't calculate the value the authentication server expects. I suspect "key" in the beginning of the text refers to a keyfrob/hardware security token.
    – eckes
    Commented May 14, 2017 at 1:14
  • This may be of use: ietf.org/rfc/rfc4226.txt
    – jrtapsell
    Commented Jun 1, 2018 at 6:55

3 Answers 3


A seed is a non-secret value used as a starting point. I'm not sure what it's the starting point for, but presumably the algorithm needs a (relatively well-chosen) number to start from.

Based on the Wikipedia article, the key is not known only by the client; the server knows it too. The HMAC is a method for disguising the shared secret in such a way that anyone who intercepts the communication doesn't learn the shared secret, and thereby gain permanent access to your account (similar to digest authentication).


Key in this case is a hardware device. Also known as Frob or Dongle or Token (or an App with limited protection against extraction). They need a secret value shared between the service and is embedded into the key in a way it cannot be extracted (easily).

Sometimes this is called seed, sometimes key. Sometimes it's a combination of a random number unique to the hardware and a key uploaded. In case of TOTP the seed for the iterative calculation is also the shared secret. But when provisioning a new key it might also use a seed as a base for calculating the shared secret.

The counter is either a counter counting the number a button is pressed on the device or it is time Intervalls since a certain time. The button version has the advantage that it does not need a clock (but needs a non volatile counter storage), the timer version is easier to use (and most common).

The 'phishing protection' however is limited: an attacker stealing a OTP code will be able to use it once, they just cannot login repeatingly. So I would not consider phishing protection as the major security gain for a OTP.


In my case:

I use a authentication system called BetterSeal which uses Authkeys to give users/clients authentication. In my case, if someone tried to login into my loader/panel then they would need an Authkey that is generated and stored on BetterSeals server which would answer your question on if its client side or not. Both the client and server need to communicate to get access.

What is meant by seed?

It is a hash or sort of key (usually very long) that is unique to a certain session or client.

And the counter is related to what?

I think this means the session limit/time. (ex: 1 minute, 1 hour, 3 months, lifetime)

How can it be match if the key is secret?

There is a Application/Web Auth Token (looks like a hash/seed too) which is used to talk to the Authkeys. These are connected to each other. If the Application/Web Auth Token is deleted or removed the Authkeys will not be connected leading to unusable Authkeys. It's basically like losing access to a server, which makes your login credentials usable until the server comes up.

You must log in to answer this question.

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