New answers tagged

4

Since you know that your plaintext tokens are unique (or at least this is a logical inference) you don't need a salt. The salt's intention is solely to provide hash-uniqueness in the case of identical passwords, but since your input space is intended to be guaranteed unique, you don't have this problem. Additionally, since you have control over the ...


3

You can use bCrypt. The simple solution is sending your user a an Id and the Token: https://example.com/pwdReset?resetId=123&resetKey=[your long randomly generated key] You can lookup the hash using the id (just like you would use the username to lookup the user's password hash).


2

You may be interested in reading: HOTP: An HMAC-Based One-Time Password Algorithm (RFC 4226) TOTP: Time-Based One-Time Password Algorithm (RFC 6238) Both of them describe standard ways of creating a One-Time Password. Do all (standard) hardware OTP tokens require the developer to pass the OTP to the manufacturer's server for verification? There ...


2

As stated in your other post: No. You do not need to pass the OTP value to the manufacturers site. Usually - if you are buying pure OATH/HOTP tokens cheap in china (like Feitian), you will not even be able to do this. You need to run your own server like privacyIDEA. The smartcard is usually no OTP token. However, some smartcards like from Gemalto indeed ...


1

@JeffMeden and @billc.cn already gave a very good explanation. In your original question you mentioned something, I would like to comment on: You said "You send the OTP to your app which in turn asks the manufacturer's server if the code is correct". This can be true in some cases like the yubico validation service or services like duo or onelogin. These ...


3

@JeffMeden gave a good overview of how PKI smartcard work, he failed to point out that they use completely different protocols and security models compared to OTP tokens. An OTP token uses some kind of pre-agreed secret* to generate a password. The protocol can only prove someone at the time holds the token. It cannot verify the identity of the server nor ...


3

The smartcard based systems like the product in the link you provided are based on PKI (public key infrastructure) which is a means to authenticate a user based on their ability to sign something with a private key (held on the smartcard) that can be proven with application of the public key. Since the private key never leaves the card (at least, in fully ...


0

This is how I would do it. Have the web app generate a public/private pair (say DH). Show the public key on the screen as QR code, the user then scans it with the phone. From this point onward, the phone can send anything to the web app securely.



Top 50 recent answers are included