Upgrade cryptography for 2x increase in security, with a hash-function to hide the next public-private key pair

Currently, almost all public-private key systems are elliptic curves, a [monoculture](https://www.sciencedaily.com/terms/monoculture.htm). One simple idea I had for improving security, is

`proof_of_public_key = keccak256(nextPublicKey)`

that each transaction includes a proof of a new public-private key pair. To attack an account, an attacker would first need to break the hash function, and then the asymmetric cryptography, which is why there is roughly 2x increase in security. The authentication method relies on two cryptographic assumptions, a hash function, and a public-private key pair.

Accounts could also not switch key pairs, by leaving `proof_of_public_key` blank in their transaction, which makes it backwards compatible with what people are used to at the moment, while allowing a simple 2x increase in security for anyone who wants to adopt that.

The authentication method has only a very small increase in transaction size, an added field `proof_of_public_key`
with a 256-bit value, and those who do not adopt the authentication method will just leave `proof_of_public_key` blank, so almost no increase in transaction size for them.

View Reddit by johanngrView Source

Authy Is an awesome App – BUT there is one major security flaw.

**tl;dr**: Authy is flawed in that it’s own native tokens are not as well protected as Google Authenticator / RFC 6238 tokens that you can add


I see Authy getting recommended a lot here, and as one of the major supporters of this app, I couldn’t be happier because I really do believe in having a good system of security that not only allows us to adopt better security (implementing 2FA for all our accounts), but to also do so without a loss in convenience (cloud backups). However, I do have to point out that one of its major flaws is that it doesn’t protect Authy tokens with the same security it does with RFC 6238 / Google Authenticator tokens. I’ll explain a little more in my post below, but let me first run through the details of Authy.

**Authy’s Security Model**

I’ve always respected this model because it’s a lot like LastPass’ where your data is encrypted by a key that only you know. I studied this quite a bit and was impressed by their use of this concept. It gives me reassurance that accounts are protected and moreover by a password that only I know. [Authy even explains it in a lot of detail here](https://support.authy.com/hc/en-us/articles/115001950787-Backups-password-Master-password-and-PIN-protection-with-Authy) to tell us how secure the backup passwords are.

**Authy Tokens vs RFC 6238 TOTP Tokens**

Authy was originally made as an 2FA API itself. Now as a disclaimer, I’m not a software expert or anything, so I’m stepping on thin ice here in my discussion, but it seems Authy has its own token system that’s slightly different from Google Authenticator / RFC 6238.

As one of the early users of Coinbase, they partnered up with Authy for 2FA initially, so all you had to do was tie your phone number to Coinbase and Authy and it would enable the Authy token automatically. A few other services today continue to use Authy tokens ([Gemini](https://authy.com/guides/gemini/), [Twitch](https://authy.com/guides/twitch-3/), [Twilio](https://authy.com/guides/twilio/) obviously, BitGo, and maybe a few select others). The problem I noticed was that these tokens are separate from Google Authenticator / RFC 6238 tokens that you typically add through a QR code or a seed phrase.

**The Problem**

These Authy tokens are NOT protected by the backup password that your other tokens are that you manually add via QR code..

Now you might not understand what an Authy token is, so feel free to look at those links for Gemini, Twitch, and Twilio that I posted above. You will notice that the setup involves typing in your phone number rather than a QR code. Since Authy also has your phone #, giving your number basically adds that token to your Authy account by linking the two together using that identifier. You may also notice that these Authy tokens are 7 digits instead of your typical 6 digit 2FA codes.

**How to Replicate the Problem**

What I hate more than anything else about PSAs is the people posting issues that only affect them, and don’t do proper debugging to even reproduce the problem. While I thought I discovered this issue a while ago, I didn’t make this post until I finally sat down and spent some time playing with multiple phones, tablets, computers, and accounts. I went ahead and tried this not only on my account but setting up a dummy account and confirmed both times that Authy tokens really aren’t protected by a password. I encourage you to try the following steps:

1. Setup a new Authy instance either on a new phone/tablet or Chrome. Or if you already have Authy on every device, just remove it from one and try setting it up again.
2. Confirm your new device via an old device or via SMS
3. Open up Authy and look for your Authy Tokens. [I’ll show you my Authy screen,](https://i.imgur.com/HuYo6s4.png) This was a brand new laptop I had just setup and installed Chrome. You can notice that all my Google Authenticator tokens are LOCKED. [I need to type in my backup password before I can even use those tokens](https://i.imgur.com/V0CqYl9.png). But BitGo there is an Authy token. [It’s fully unlocked. I can click on it without typing any password.](https://i.imgur.com/bkqQuoT.png)

**What’s the problem with this?**

Well I’ve seen many recommendations for Authy offer reassurance that even if your SMS is spoofed/hacked, that a hacker still needs a password to access your 2FA tokens. **NOT ENTIRELY TRUE!!!!**

Your Google Authenticator tokens **will be protected by the secure backup passwords** **but your Authy tokens will not be.** I’m going to guess this is why [Coinbase started migrating over to Google Authenticator instead of defaulting to Authy](https://www.reddit.com/r/Bitcoin/comments/6f0hhb/coinbase_recommendation_migrate_from_authy_to/) due to the threat of SMS being so easily hijacked.

**Damage Control**

So because your Authy accounts can be accessed w/o a password, anyone who can intercept your SMS codes can get access to your Authy accounts. The best way to mitigate the damage is to disable the “Allow Multi Device” setting in the Coinbase app. This prevents any other user from setting up new Authy devices with your account. Turn it on when you need to setup a new phone/device, but turn it off immediately after.

While this seems to prevent anything bad from happening, it’s a band-aid solution. Authy’s tokens may be encrypted on their servers, but it’s certainly not encrypted with a password that only you know (it’s either that or they know your backup password in reality). It would seem if someone hacked their servers, that they could get control of your Authy tokens even if your Google Authenticator accounts are still protected. So in conclusion this puts in doubt their backup password security explainer:

>This means that if our servers were to be compromised, no hacker would be able to steal your tokens unless he also knew your backups password.

View Source

View Reddit by dlerium