First, a note of caution: Unless you securely receive and verify the user's public key ("Security Number" or whatever WhatsApp calls it), WhatsApp is no more secure against spoofing than normal SMS is (because normal SMS is the only way it authenticates users). If you're trying to avoid using SMS because it's expensive, then WhatsApp is a reasonable alternative; just don't think that it's dramatically more secure than SMS. It is arguably more secure in that it's encrypted end-to-end, so it can't be intercepted en route, which is a significant risk with SMS. However, it's also more likely than SMS to be routed to multiple devices (one if which might have been stolen or shoulder-surfed), and/or for a user to still have a WhatsApp number that is no longer their phone number (in which case the WhatsApp account could be stolen from under them at any time). If you want to add some extra degree of security, your WhatsApp client could record the user's public key when they set up the WhatsApp auth factor. That way, if something happens to their WhatsApp account, you'll know because the public key will change. To actually answer your question: it's arguably better to use the QR code, since that can be sent through an already-authenticated channel (the HTTPS connection to your front-end, presumably a webpage), and then let the user respond from an account that they trust. Simply sending the code to a number has a small risk that it's not a number the user controls any more (maybe they recently changed numbers and gave you the new one, but hadn't updated their WhatsApp account yet, and somebody else had gotten the old number and set up WhatsApp to route that number to them). There's also a small risk that the user just made a typo entering their phone (WhatsApp) number. In either case, you risk sending the second-factor code to the wrong person, who - if they can guess the legit user's password - could then log in as the user. Otherwise, though, it doesn't matter. Most likely you'll answer this question for other reasons (cost and user experience) rather than security. That's especially true if you expect your users to rely on WhatsApp enough that there's almost no risk they'd make the mistake described above (though note: people get their email address wrong all the time; getting a phone number wrong is pretty easy). While you're at it, consider adding support for https://webauthn.guide/ (see libraries https://webauthn.io/ ), which can use either hardware tokens (e.g. Yubikey, Titan Key) or platform security (OS login methods such as FaceID, TouchID, Windows Hello, Android's fingerprint scanner, PIN, etc.) to securely perform public-key-based authentication. WebAuthn can be used as either a second factor or as the only factor, and is the only authentication system I'm aware of to provide really strong anti-phishing protection (the public key is unique per site; even if the user doesn't realize they're on the wrong site, their browser will send a different public key). It's also often more convenient than OTPs or TOTP (e.g. Google Authenticator).

Is this a valid way to do this or it contains some security flaws, if yes what security problems may arise here? You generate the secret on the users device, and then send it to the user. It's probably trivial to rewrite your application to simply tell the server a random phone number, and Yup, this number really verified just fine! This doesn't offer security, and is just a waste of time. To make this secure, the client should transmit the phone number to the server, and the server should generate a secret and send this via SMS to the provided phone number. This is not fool proof, as there's avenues for intercepting or hijacking text messages, but it will be magnitudes better than your current scheme. In addition, as pointed out by https://security.stackexchange.com/users/242928/bk2204 in a comment, Random() https://www.geeksforgeeks.org/random-vs-secure-random-numbers-java/ . It's not meant to be used for secrets, and past codes may reveal future codes, and the seed is commonly the time of the machine - which can be brute forced easily.

This is not a Sim Swap Attack. On a Sim Swap Attack, your phone loses data connectivity because your SIM is marked as lost or stolen, so that SIM cannot connect back to the network. The only way to get connection back is to get another SIM, or having your company restore your SIM status. What is more likely is that someone (maybe you) installed malware on your phone, and that malware is sending your messages to them. Take a look on all applications you have installed, change your passwords, verify on your iCloud account what can access it (check your devices in iCloud settings, and double check they don't have malware installed (especially on Macs if you have any)) , those kinds of things. Are there any ways to definitively detect if this is sms spoofing, or some kind of malicious mind game? This is definitively not SMS Spoofing. It would be a malicious mind game if people who are harassing you and those you are in contact are together on this.

It's probably best to ask the user what they want to do, after they sign in (including 2FA if needed). In particular, offer the ability to: [Default] Forget the other account on this device (requires 2FA for it when they next sign in) Remember both on this device (neither will need 2FA in the future, for the usual time period) [Optional] Combine accounts such that either one can be used to authenticate the other (also requires authenticating the other account at the same time). You can of course provide suitable advice warnings about the risks (option 1 is default behavior and what you should always use with a public computer, option 2 is for shared computers where people mostly trust each other but if you don't want to let others bypass 2FA for your account you need to explicitly sign out, option 3 [if offered] is for the same person with multiple accounts, and shouldn't be used with anybody else you don't trust in the "joint account" sense). Ultimately, though, the decision is already in the user's hands - they could use different browser profiles, or different OS user accounts, or different browsers, or a shell script that swaps out the cookie/local storage DB on demand (which is basically a hack for browser profiles, of course), or whatever - so the goal is accommodate their needs without making other users less safe. For the technical details, it depends a lot on how you remember devices. If it's an opaque token per user, you'd need to adjust the storage format to either tolerate a list of tokens or store multiple tokens in different records (e.g. prefixed with a user ID) and send the appropriate one (or all of them, e.g. if they're stored in cookies, and let the server sort it out), or you need to update the back end such that a single opaque token can refer to multiple users. That last option shouldn't actually be hard; presumably each user can have multiple devices already, so if you store a unique token on each (instead of reusing the tokens, which shouldn't be possible because they should be hashed in the DB) then you need a table of token:UID mappings, and if you remove the constraint on uniqueness of the token, one token can map to multiple UIDs). If you instead use JWTs or similar signed tokens, you can easily mint a new token that is valid for multiple parties (does require updating the server to handle this case, but should be easy). With all that said... consider switching to (or at least offering) a better 2FA method. Webauthn supports a wide range of authentication agents; it's perhaps best known as a way to use security tokens like Yubikeys, but it can also be used with biometrics and/or platform authentication (e.g. Windows Hello on Windows, TouchID/FaceID on MacOS/iOS, fingerprint or device lock code on smartphones, etc.). These are generally sufficiently low-effort that the cost of using them, even every time you sign in at all, is not a problem. If you're "sending" a 2FA code through anything other than a push notification, that's probably either SMS (not very secure) or email (widely varying security, although usually acceptable these days).

The main way that OTPs are weaker than regular passwords is that they need to be made available to the user through some method, before the user has authenticated. There are a few ways to do this, with widely varying security. For example, SMS is very weak - it's considered weak even for a second factor, so using is the only factor is extremely poor security - because it's relatively easy to intercept, re-route, or access on a stolen device (lots of phones configured to display SMS even on the lock screen). On the other hand, an OTP from a hardware device or phone app (could be HOTP or TOTP, the latter better known as the algorithm Google Authenticator uses) is generally pretty safe (though still weaker, if used alone, than almost any two-factor approach). OTPs are also often weaker than traditional passwords in that their maximum entropy is much lower, and they're easy to enumerate. Typical six-digit OTPs have a million possibilities, or roughly 20 bits of entropy. That's as much as a decent but not great password. The odds of anybody successfully guessing it are generally low enough to not worry about, but it's well within the range that a large botnet could brute-force trivially if you don't have protections against such threats. On the other hand, if you allow the user to request OTPs (e.g. for delivery by SMS or email), and each request delivers a new OTP (because you're hashing them in the DB, to reduce the risk of them being exposed while still valid), then the attacker could make their job a lot easier. Suppose they are able to get 1000 OTPs valid at once for a given user; then they have a 1/1000 chance of guessing right, and that's doable with a single Internet connection and at most a few minutes. There are ways to protect against this, of course - rate-limit requesting new OTPs, disable existing OTPs when a new one is requested, deactivate all OTPs for a given user if there are some small number of wrong guesses, monitor for things that look like brute-force attacks and block them possibly by disabling the targeted user account - but these all have their own threats as well (usually that an attacker can prevent another user from logging in, though this threat also exists for traditional passwords). It should be noted that your two threats miss the biggest threats BY FAR: phishing and credential stuffing. In terms of real-world compromises, phishing almost certainly causes the greatest monetary losses to businesses and probably also individuals, but credential stuffing (reusing a compromised password from site X to log in as the user on site Y) is also common. (You might argue that a "user with proper password management" precludes password reuse, but in the real world people reuse passwords constantly, often even if they also use a password manager, and if you're choosing the auth systems to support, you have to take real-world user behavior into consideration.) OTPs eliminate the credential stuffing attack, and in that way are a substantial improvement over traditional passwords. However, they don't help against phishing; if the user expects to be entering an OTP, and they get an OTP, they will enter it (even if the site they enter it into is actually an attacker's phishing page). If the session is short-lived and requires a new OTP to log in again once it expires, that that limits the damage possible from a single phishing success, but usually sessions can be long-lived after you've authenticated once, and even short-lived access can do a lot of damage.

A rather simple way would be to encrypt the file in sequence with the keys of all its owners. Algorithmically it would be: orig -- key A --> encA # and destroys orig encA -- key B --> encB # and destroys encA encB -- key C --> encC # and destroys encB To recover the original file, you would just do the opposite encC --> key C --> encB encB --> key B --> encA encA --> key A --> orig The good point is that the decryption does not need to be simultaneous, because each key owner could just send their partial decryption to the next one. The bad point is that you should find a way to prevent A to keep a copy of orig or encA: if they do, they would be able to access the original data without the other keys.

Yes, it contains all the keys so it can serve as a backup. Making such a backup causes a google authenticator to display a warning, so keep your phone away from others until that warning expires, else you'll not be able to tell if they have also cloned your keys.

Yes, OTP is adding extra security. If a hacker gets your password by guessing or shoulder surfing, your account with no OTP is doomed. If you have OTP for your account, the hacker still cannot break into your account, even if he got one OTP code before. If you keep OTP seed separately in a well-designed app, it is more secure. But if you put them in some cloud-based app without end-to-end encryption, I doubt.

TOTP is indeed a time-based variant of HOTP. In both cases, the sequence of possible passwords is derived from a secret key, and a "changing value". With TOTP, the "changing value" is the current time, which both ends of the protocol supposedly know (current time is public knowledge). In HOTP, the "changing value" is a counter, which is incremented after usage. Both parties (client and server) remember the last used counter value. If the client and server become desynchronized (e.g. the client sent a password and incremented its counter, but a network issue killed the connection and the server never received it), then there is a process for resynchronization: upon receiving a password, the server compares it not with the next password (according to its counter), but with the next 100 or so passwords, thus allowing for a counter desynchronization of a 100 or so. This mechanism is well suited to car keys, which: Do not have a common source of time (no clock in the key). Need to work with a unidirectional communication (from key to car, not the other way round). Have a "manual resynchronization" if they got badly out of sync (your 3 years old nephew played with the key for an entire afternoon, getting the key counter way beyond the car counter, even with the +100 offset; you can no longer open the car remotely; but when you ignite the engine, the car and the key communicate through short-range RF to reset the counters). As for code, a simple google request on "hotp php" points to this and that.

MD5 type encryption seems a bit pointless given how quickly it can be decrypted, Don't get your terminology mixed up. MD5 is a hash algorithm, not an encryption algorithm. There is a world of a difference between the two. To answer your question, I don't see an issue with storing the seed unencrypted together with the username and password in a database. A TOTP seed is easy enough to reset if you ever get compromised. You need the seed in cleartext for the algorithm to work anyway.

The TOTP specification points, for the security analysis, to HOTP. HOTP uses a counter, shared by both parties, and "resynchronized" every time a successful authentication occurs; TOTP replaces that counter with knowledge of the current time, which is also a shared value. As such, almost all the security analysis of HOTP applies to TOTP. The security analysis of HOTP uses the formal tools and notations of cryptography, but boils down to the following assumption: Let T denotes the time to perform one computation of H. Then if A is any adversary with running time at most t and making at most p oracle queries, Adv(A) <= (t/T)/2^k + p^2/2^n In practice, this assumption means that H is very secure as PRF. The important word here is PRF: it means that the "H" function (HMAC/SHA-1) behaves, in the view of the attacker (who does not know the key) like a function chosen "at random" among all possible functions. We give the attacker access to an "oracle", which is a machine which knows the key, and computes HMAC/SHA-1 over inputs chosen by the attacker; the attacker can send p such queries. The expression above means that even under these conditions, the probability that the attacker successfully predicts, after all his queries, the output for one extra input (that he did not send to the oracle), is still very low (the "advantage" is what extra success probability the attacker has over pure luck). Right now, it seems that HMAC/SHA-1 behaves as a PRF. Nobody has found any indication to the contrary. This holds even in the face of the known structural weaknesses which seem to allow (theoretically) some computing SHA-1 collisions. From this assumption, the security proof of HOTP (as exposed in RFC 4226) establishes the following result: Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP using v verification oracle queries, a Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller than the sv(q + 1)/2^n term, so that the above says that for all practical purposes the success rate of an adversary attacking HOTP is sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP algorithm is in practice essentially as good as its idealized counterpart. This last paragraph is what you are after: under the assumption that HMAC/SHA-1 is a PRF, it is proven that giving access to a lot of previous one-time passwords does not given any advantage to the attacker for guessing the next one, at least no more that what he would get out of an "ideal" version of HOTP in which the one-time passwords are obtained through pure unpredictable magic. Summary: No need to worry. Resistance of HOTP (and TOTP) to the situation where many previous one-time passwords have been recorded is part of the security model of HOTP, and it has been specifically shielded against such an occurrence. The shield here relies on an assumption of security on HMAC/SHA-1, which, while not proven, is about as good as these things can get (notably because it is quite possible that the fact that a function family is a PRF might be mathematically impossible to prove; see this for more on that subject).

No. Security remains the same + extra cognitive overhead. Presumably the plugin uses OATH HOTP where the KeePass file or master key is re-encypted after each access with the next one-time-password. However to generate the next password on the device, the plugin would require either a secret stored on the device or the normal password for the KeePass file. Security from a one-time-password comes from two parties knowing the same key and counter - HOTP(Key,Counter) - while an attacker doesn't know the key. If the attacker has access the device storing the KeePass installation and files, the security re-collapses to the security of the normal password on its own. If the KeePass file is still interoperable with other KeePass programs, then you gain nothing from using a one-time-password in this fashion. One-time-passwords work well for server authentication because both client and server end-points are considered secure and the attacker needs 'something you own' as well as 'something you know'. If the attacker has your computer, then they now have 'the thing you own'.

I'd say just a code on the phone is weaker than username and password (because you can loose a phone and someone might abuse it). Combining them is a form of multi-factor authentication: something you know (password and username) something you have (phone with text message) and depending on the level of authentication you need, this is considered a good and strong form of authentication.

Google Authenticator supports both the HOTP and TOTP algorithms for generating one-time passwords. With HOTP, the server and client share a secret value and a counter, which are used to compute a one time password independently on both sides. Whenever a password is generated and used, the counter is incremented on both sides, allowing the server and client to remain in sync. TOTP essentially uses the same algorithm as HOTP with one major difference. The counter used in TOTP is replaced by the current time. The client and server remain in sync as long as the system times remain the same. This can be done by using the Network Time protocol. The secret key (as well as the counter in the case of HOTP) has to be communicated to both the server and the client at some point in time. In the case of Google Authenticator, this is done in the form of a QRCode encoded URI. See: KeyUriFormat for more information.

I don't explicitly know the answer to your sourcing problem, but I do know a bit about the cards and their internals. That being said, I'm pretty sure GIS manufactures them. There are two classes of card internals: Discrete small pitch surface-mount components embedded inside the plastic. Custom chip-on-board encased in epoxy, again embedded in the plastic. The first one can be seen by cutting the card's layers apart with a very sharp scalpel. It's tedious work, but you can often find all sorts of interesting internals. You can also "image" the internal layout with a high resolution baggage scanner or similar equipment. The second one is more difficult to work with. You can cut the card up, but you'll just find a black blob. You can use corrosives to dissolve the epoxy and reverse engineer it, but that's annoying and often damages the internal die. If you want to build your own, it's actually not hard. Just buy a bunch of tiny SMD components that do the job (they're often significantly thinner than a card), wire them together using thin patch wire, use a dremel to drill down into the guts of an existing card, solder your wires to the card contacts, then use epoxy to fill it. You can use fine sandpaper to flatten it down nicely. It doesn't look very professional, but the card works.

What you are trying to do is a great challenge and currently isn't possible. There has been some discussion about using TPMs to provide a vendor locked trusted environment that could be used as the basis of such a system, but the problem currently is that an untrusted system can not prove itself trustworthy since any inspection a trusted system could do could be faked. You have to have some trusted subsystem on the client that can do the validation actively. When all you have is a request from the client, you lack the access and level of trust necessary to achieve your goal.

HMAC/SHA-1 is not broken. SHA-1 has a weakness with regards to collisions (and it is still "theoretical" since producing a collision for SHA-1, though conceptually easier than the generic attack, is still so expensive that nobody has computed one such collision yet). But HMAC resistance does not rely on resistance to collisions. Indeed, HMAC is proven secure as long as the hash function which it uses is a Merkle-Damgård function which itself relies on an internal "compression function" which behaves like a PRF. This is rather technical. To make a long story short, the known weakness of SHA-1 voids the proof, but nobody knows how to turn that into a weakness on HMAC/SHA-1. Empirically, we have the example of MD4: MD4 is extremely broken with regards to collisions, with a near-zero cost (computing a collision for MD4 takes less time than actually hashing the two colliding messages to verify that it is, indeed, a collision), and HMAC/MD4 is also broken, but with a quite non-trivial cost of 258 plaintext/MAC pairs (and that's a forgery attack, not even a key recovery attack), making it utterly non-applicable in practice. If we have the same kind of ratio for SHA-1, then HMAC/SHA-1 is still very safe. Nevertheless, HOTP can be used with any hash function but this requires "adaptations". On a general basis, thou shallt not fiddle with cryptographic algorithms. That being said, it is rather obvious (at least for a cryptographer) that replacing SHA-1 with "SHA-256 truncated to 160 bits" in HOTP will yield something which is equally secure (i.e. the detailed security analysis of HOTP fully applies with that alternate hash function). However, changing the hash function means that you can no longer test your implementation with regards to the published test values, and that's a big worry. Implementation bugs are a much more common source of practical vulnerabilities than cryptographic weaknesses. Therefore, use HOTP with HMAC/SHA-1 and be happy. It is not broken.

The tricky point is pre-usage synchronization. When you want to use a one-time password, the client must "somehow" learn the one-time password to use. HOTP is for situations where this out-of-band synchronization is through a counter which is maintained both client-side and server-side. If you have another out-of-band mechanism which can be invoked on a per connection basis (e.g. a SMS), then you do not need the counter management that HOTP provides. HOTP is also a good PRNG, but it is simpler to generate random one-time-passwords from the OS facilities (/dev/urandom and its ilk). As you point out, HOTP is similar to a PRNG with a secret key, and key theft implies compromise. With a fresh random password for each connection, an attacker who can peek at the server database might learn the current OTP for a given users, but will know nothing about the next OTP, so the damage is contained in time. Using HOTP (or its time-based variant TOTP) in the SMS-based scenario is not awfully weak -- this is a good model which supports user tokens. HOTP is sane usage of cryptography. But if you have an out-of-band channel available for quasi-immediate transmission of the OTP (such as a SMS), then you can use random generation which will be even better.

There are some explanations on what YubiKey does here. Basically, the password which the YubiKey "types" (from the point of view of the computer, it is a keyboard) can be either a static password, or a one-time password. If it is a static password, then you just revealed it, and it is time to be very sorry (and promptly change that password). The one-time passwords, what YubiKey produces follows HOTP. The cryptography in HOTP is such that it is not computationally feasible to recompute the "master secret" from one or several one-time passwords produced with HOTP. Moreover, each password is internally computed from a counter. The YubiKey and the server both maintain the same counter, and the server allows for some limited lack of synchronization. Namely, when the server's current counter has value n and receives a password as authentication attempt, it will internally generate the passwords for values n+1, n+2,... up to, say, n+100 (that's configurable). If a match is found with (say) password n+17, then access is granted and the server's counter is set to n+17; otherwise, connection is rejected and the server's counter is not changed. Therefore, what you inadvertently published "on the Internet" is a password which will grant access to the corresponding server, until your own next authentication on that server, because that authentication will update the server's counter to a further counter value. In a way, using OTP with counter value k invalidates all OTP values with values j < k. Which leads to the following recovery procedure: if you published an OTP value, quickly connect to the server so as to invalidate that published value. Afterwards, you can just ignore it; once invalidated, it is harmless. (Note: if you repeatedly generate a lot of "blank" passwords with your key without authenticating to the server, your YubiKey may go out of synch with that of the server -- the key using counter values way beyond what the server would currently accept. Don't let your 3-year-old play with your YubiKey ! In a similar situation, for infrared car keys, counter synchronization is forced through RFID when you start the engine.)

I don't know about 'Vasco Digipass Mobile SDK OTP generator' particularly, but I have evaluated Software OTP generators in the past and these are things I would look at. Is the app protected by a PIN? If it is protected with a PIN, then what happens when you key in a wrong PIN? Does it still generate an OTP or does it report an error message. The relevance of this question: An OTP generator uses a secret key which is shared with the Authentication server. Now the secret key has to be stored somewhere on the device & hence it's vulnerable if the device is lost. Hence it's better if the app is protected with a PIN. Now next question is where is the PIN stored? If the PIN is stored on the device then the protection again becomes meaningless. Because just like the secret key, the PIN also would be vulnerable to attack if the device is lost. So what's the alternative? First alternative is to use the PIN to encrypt the secret key & not store the PIN on the device. However, this is still not a good method because, once the device is lost, it can be brute forced. So what's the better alternative. The OTP generation uses both the PIN & secret key as inputs to the OTP generation algorithm. In this case, if you type the wrong PIN, then the OTP is still generator because the app does not know if the PIN is correct or wrong. However, if you type in the wrong PIN, then the OTP generated would be wrong. Because the Server would be generating the OTP with the right PIN and hence it wouldn't match the one generated by the app. i.e. the PIN is implicitly verified and not explicitly verified. So how would you know if your app stores the PIN locally or uses the PIN to encrypt the secret key, then app typically gives an error message when you type in the wrong PIN. Whereas, if the PIN is not stored locally, then the app doesn't give an error message with the wrong PIN. What algorithm does the OTP generator use? Does it use a Time based algorithm or an Event (Counter) based algorithm. Hardware OTP generators always usually use a Time based algorithm, but a lot of Software based OTP generation apps use Event based because the assumption is that the time on the mobile device may be off - may not be in sync with the server time. How is this relevant? Event based OTPs never expire. Or actually they expire only when they are used or when a more recent OTP is used. If you use your OTP generator app to generate an OTP now, you can note down the OTP & use it after any number of days as long as you haven't done any other authentication in between. i.e if you generate 2 otps & note them down, then if you use the 2nd OTP for an authentication, it will work, but the 1st one automatically expires. Since Event (Counter) based OTPs do not expire they are a little more easily offline attacked then the time based OTP. Is there a mitigation for this. There is another Event based OTP algorithm called OCRA (Challenge Response based). Here the server throws a challenge which has to be input into the app before it generates the OTP. IMHO, for a mobile device (where you may not be able to use Time based OTPS), an event based one which uses the Challenge Response mechanism may be better than a plain Event based one. However for lay users, it may be a little confusing. How is activation done? Is the shared key sent over SMS or something like that? That may make it a little insecure. Some OTP generators are activated by negotiation - i.e. the client and server negotiate the shared key using some standard like DSKPP. These may be more secure than the ones where the key is sent over SMS.