How are one-time password generators like Google Authenticator different from having two passwords?How safe is Two Factor Authentication (TOTP)?In a TOTP implementation, does there need to be an expiration policy for the user's secret key?Why do I see 2FA but not see “two separate entities” being prioritized in website authentication?Multi-Single-Factor vs. Multi-Factor AuthenticationDoes producing TOTP tokens weaken the stored secret? How much?Does the existence of two-factor recovery codes mean that my 2-factor code isn't completely random?Does the TOTP Algorithm rely on the client time always being synced correctly?Storing TOTP secret in database, plaintext or encrypted?Is it reasonable to store encrypted TOTP keys + authentication credentials on a single device (for end-user)?Can a Time-based One-time Password (TOTP) key be decoded from generated values?
Why A=2 and B=1 in the call signs for Spirit and Opportunity?
Question about Shemot, locusts
Why is the Eisenstein ideal paper so great?
Why was this character made Grand Maester?
Count all vowels in string
What is to the west of Westeros?
Where is Jon going?
Is superuser the same as root?
The disk image is 497GB smaller than the target device
What is the use case for non-breathable waterproof pants?
Is keeping the forking link on a true fork necessary (Github/GPL)?
Why'd a rational buyer offer to buy with no conditions precedent?
Why did it take so long for Germany to allow electric scooters / e-rollers on the roads?
Are there historical examples of audiences drawn to a work that was "so bad it's good"?
Why does Bran want to find Drogon?
How does the Earth's center produce heat?
Why did other houses not demand this?
What is the function of は in the context?
Why does the painters tape have to be blue?
What is Orcus doing with Mind Flayers in the art on the last page of Volo's Guide to Monsters?
Did significant numbers of Japanese officers escape prosecution during the Tokyo Trials?
"Official wife" or "Formal wife"?
Flatten not working
Testing using real data of the customer
How are one-time password generators like Google Authenticator different from having two passwords?
How safe is Two Factor Authentication (TOTP)?In a TOTP implementation, does there need to be an expiration policy for the user's secret key?Why do I see 2FA but not see “two separate entities” being prioritized in website authentication?Multi-Single-Factor vs. Multi-Factor AuthenticationDoes producing TOTP tokens weaken the stored secret? How much?Does the existence of two-factor recovery codes mean that my 2-factor code isn't completely random?Does the TOTP Algorithm rely on the client time always being synced correctly?Storing TOTP secret in database, plaintext or encrypted?Is it reasonable to store encrypted TOTP keys + authentication credentials on a single device (for end-user)?Can a Time-based One-time Password (TOTP) key be decoded from generated values?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Google Authenticator uses the TOTP algorithm to generate your One-Time Password (OTP). TOTP works like this : The server generates a secret key and shares with the client (you) when the client registers with the server. Using the shared key and the current timestamp, a new password is generated every 30 seconds.
If anyone has the shared key, then they can generate the OTP themselves using the TOTP algorithm. Isn't this similar to a password? Doesn't it get reduced to having two passwords - One is the password that you use to login and the other is the shared key between you and the server?
multi-factor google totp
edited May 9 at 13:19
Machavity
2,399620
asked May 9 at 3:08
AshwinAshwin
86731423
add a comment |
Google Authenticator uses the TOTP algorithm to generate your One-Time Password (OTP). TOTP works like this : The server generates a secret key and shares with the client (you) when the client registers with the server. Using the shared key and the current timestamp, a new password is generated every 30 seconds.
If anyone has the shared key, then they can generate the OTP themselves using the TOTP algorithm. Isn't this similar to a password? Doesn't it get reduced to having two passwords - One is the password that you use to login and the other is the shared key between you and the server?
multi-factor google totp
edited May 9 at 13:19
Machavity
2,399620
asked May 9 at 3:08
AshwinAshwin
86731423
The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
– JimmyJames
May 10 at 16:14
add a comment |
Google Authenticator uses the TOTP algorithm to generate your One-Time Password (OTP). TOTP works like this : The server generates a secret key and shares with the client (you) when the client registers with the server. Using the shared key and the current timestamp, a new password is generated every 30 seconds.
If anyone has the shared key, then they can generate the OTP themselves using the TOTP algorithm. Isn't this similar to a password? Doesn't it get reduced to having two passwords - One is the password that you use to login and the other is the shared key between you and the server?
multi-factor google totp
edited May 9 at 13:19
Machavity
2,399620
asked May 9 at 3:08
AshwinAshwin
86731423
Google Authenticator uses the TOTP algorithm to generate your One-Time Password (OTP). TOTP works like this : The server generates a secret key and shares with the client (you) when the client registers with the server. Using the shared key and the current timestamp, a new password is generated every 30 seconds.
If anyone has the shared key, then they can generate the OTP themselves using the TOTP algorithm. Isn't this similar to a password? Doesn't it get reduced to having two passwords - One is the password that you use to login and the other is the shared key between you and the server?
multi-factor google totp
multi-factor google totp
edited May 9 at 13:19
Machavity
2,399620
asked May 9 at 3:08
AshwinAshwin
86731423
edited May 9 at 13:19
Machavity
2,399620
asked May 9 at 3:08
AshwinAshwin
86731423
edited May 9 at 13:19
Machavity
2,399620
edited May 9 at 13:19
Machavity
2,399620
edited May 9 at 13:19
Machavity
2,399620
2,399620
asked May 9 at 3:08
AshwinAshwin
86731423
asked May 9 at 3:08
AshwinAshwin
86731423
asked May 9 at 3:08
AshwinAshwin
86731423
86731423
The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
– JimmyJames
May 10 at 16:14
add a comment |
The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
– JimmyJames
May 10 at 16:14
The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
– JimmyJames
May 10 at 16:14
The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
– JimmyJames
May 10 at 16:14
add a comment |
2 Answers
2
active
oldest
votes
Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.
The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.
** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
2
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
7
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
14
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
4
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
|
show 11 more comments
OTPs are a way of not needing trusting someone with your password when you require them to know something of it (like that you have knowledge of it). In most implementations this is way things work anyway. Passwords are not passed around the net. Salted hashed passwords are. The problem is you don't necessarily trust that that's how everyone is doing things. Services such as google's just take that step away from the place your logging into and do it themselves.
So you're correct. The same things happen, nothing really changes. The only difference is who you trust, but that can be important.
answered May 9 at 14:40
ANoneANone
2324
24
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
4
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
9
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f209812%2fhow-are-one-time-password-generators-like-google-authenticator-different-from-ha%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.
The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.
** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
2
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
7
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
14
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
4
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
|
show 11 more comments
Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.
The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.
** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
2
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
7
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
14
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
4
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
|
show 11 more comments
Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.
The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.
** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.
The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.
** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
edited May 9 at 9:14
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
answered May 9 at 4:44
Esa JokinenEsa Jokinen
4,6261623
4,6261623
2
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
7
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
14
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
4
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
|
show 11 more comments
2
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
7
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
14
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
4
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
2
2
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
– kjack
May 9 at 8:50
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
@kjack: The comment would have been too long, so I just edited it to my answer.
– Esa Jokinen
May 9 at 9:05
7
7
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
@kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
– A. Hersean
May 9 at 9:12
14
14
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never.
– Esa Jokinen
May 9 at 9:15
4
4
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
@kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
– Cort Ammon
May 9 at 16:07
|
show 11 more comments
OTPs are a way of not needing trusting someone with your password when you require them to know something of it (like that you have knowledge of it). In most implementations this is way things work anyway. Passwords are not passed around the net. Salted hashed passwords are. The problem is you don't necessarily trust that that's how everyone is doing things. Services such as google's just take that step away from the place your logging into and do it themselves.
So you're correct. The same things happen, nothing really changes. The only difference is who you trust, but that can be important.
answered May 9 at 14:40
ANoneANone
2324
24
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
4
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
9
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
add a comment |
OTPs are a way of not needing trusting someone with your password when you require them to know something of it (like that you have knowledge of it). In most implementations this is way things work anyway. Passwords are not passed around the net. Salted hashed passwords are. The problem is you don't necessarily trust that that's how everyone is doing things. Services such as google's just take that step away from the place your logging into and do it themselves.
So you're correct. The same things happen, nothing really changes. The only difference is who you trust, but that can be important.
answered May 9 at 14:40
ANoneANone
2324
24
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
4
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
9
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
add a comment |
OTPs are a way of not needing trusting someone with your password when you require them to know something of it (like that you have knowledge of it). In most implementations this is way things work anyway. Passwords are not passed around the net. Salted hashed passwords are. The problem is you don't necessarily trust that that's how everyone is doing things. Services such as google's just take that step away from the place your logging into and do it themselves.
So you're correct. The same things happen, nothing really changes. The only difference is who you trust, but that can be important.
answered May 9 at 14:40
ANoneANone
2324
OTPs are a way of not needing trusting someone with your password when you require them to know something of it (like that you have knowledge of it). In most implementations this is way things work anyway. Passwords are not passed around the net. Salted hashed passwords are. The problem is you don't necessarily trust that that's how everyone is doing things. Services such as google's just take that step away from the place your logging into and do it themselves.
So you're correct. The same things happen, nothing really changes. The only difference is who you trust, but that can be important.
answered May 9 at 14:40
ANoneANone
2324
answered May 9 at 14:40
ANoneANone
2324
answered May 9 at 14:40
ANoneANone
2324
answered May 9 at 14:40
ANoneANone
2324
2324
24
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
4
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
9
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
add a comment |
24
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
4
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
9
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
24
24
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
"Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect.
– AndrolGenhald
May 9 at 14:48
4
4
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
This is based on personal conception, but it's not backed up by the facts.
– Esa Jokinen
May 9 at 19:50
9
9
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
– Kevin
May 10 at 3:09
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make!
– securityOrange
May 11 at 19:48
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f209812%2fhow-are-one-time-password-generators-like-google-authenticator-different-from-ha%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
– JimmyJames
May 10 at 16:14