There is power to freeze your money, because the account that you have in cold storage you can access only with some difficulty…
So if you fail to successfully do the PIN, you cannot sign the tx which is why there is 2FA.
There CAN be a backup. You know the master secret, 24 words. You can write it up, lock in a safe, AND/OR program another Legder Nano with it, and lock it up. So you do have a backup.
1 Like
You are in control, with your 2 keys. It is only a nuisiance if the 3rd party goes inoperable.
Hi, Ludo! As ususal, you are quick as lightning. I would like to try out the interface. However, I only get to the pont of getting the hash of the mater secret. Can you help me with my trial, please?
GetMasterPasswordHash
200 Success
GetRealm
200 Success
GetAccount
401 Unauthorized
I have updated AWallet and if you have developer settings enabled, on the account overview in the top navigation there is ARC14 page. You can get the auth token from it.
Note that the 2FA app is deployed on mainnet network. You do not need any assets to have on the account to generate auth token.
for this test account Q4L22PAIYJ4E76KGHGPV4RWBCPPKYI6LVVW4ESFNVB5D4NKBNCB6SJTBLM
brother bench bar arrow indoor arctic lend afraid will range truly record morning arm join evolve pear pledge tackle increase vessel this busy absent gas
The auth token is
SigTx gqNzaWfEQE/GbFFGKNOiJymEaO7kP4fUXTLpn+K4GNSK60URD/B19FSG0qosz5Xft2whigKN+MXXiwqgGetSp/t72VGUVw6jdHhuiaNmZWXNA+iiZnbOAaRD/6NnZW6sbWFpbm5ldC12MS4womdoxCDAYcTY/B293tLXYEvkVo4/bQQZh6w3veS2ILWrOSSK36Jsds4BpEfnpG5vdGXECTJGQSNBUkMxNKNyY3bEIIcXrTwIwnhP+UY5n15GwRPerCPLrW3CSK2oej41QWiDo3NuZMQghxetPAjCeE/5RjmfXkbBE96sI8utbcJIrah6PjVBaIOkdHlwZaNwYXk=
curl -X 'GET' \
'https://2famsig.k8s.aramid.finance/v1/Multisig/GetAccount' \
-H 'accept: */*' \
-H 'Authorization: SigTx gqNzaWfEQE/GbFFGKNOiJymEaO7kP4fUXTLpn+K4GNSK60URD/B19FSG0qosz5Xft2whigKN+MXXiwqgGetSp/t72VGUVw6jdHhuiaNmZWXNA+iiZnbOAaRD/6NnZW6sbWFpbm5ldC12MS4womdoxCDAYcTY/B293tLXYEvkVo4/bQQZh6w3veS2ILWrOSSK36Jsds4BpEfnpG5vdGXECTJGQSNBUkMxNKNyY3bEIIcXrTwIwnhP+UY5n15GwRPerCPLrW3CSK2oej41QWiDo3NuZMQghxetPAjCeE/5RjmfXkbBE96sI8utbcJIrah6PjVBaIOkdHlwZaNwYXk='
Returns EHF5E3S3ZMBOZTJ3WENFA3RTYMGAG5Q3YSRRF6W5MRWSWT4YDA3HQJNUXA as the account to be added for multisig
Then i call the setup method and import it in google authenticator
and test the authentication process…
Wrong pin returns false, which means that executing real multisig signing with that account will not work…
Now we need to check the compatibility of multisig in c# with js library and implement it in wallets 
F12
Uncaught SyntaxError: expected expression, got ‘<’
I don’t see the MyAlgo web wallet and Pera functionality as being related.
Pera mobile apps deals with a “something you have” - i.e. a physical device that requires biometric verification.
With standard mobile banking apps the “something you know” is a PIN.
So for Pera Mobile you’re asking for a PIN check to be added to the Pera mobile app functionality.
Am i right?
Regarding SMS 2FA - no one should be using that due to SIM impersonation attacks.
@FrankS I’m just trying to think through how there could be an additional layer of security - optionally - that would secure all outbound transactions from a wallet. Perhaps the simplest implementation would force a compact smart contract to be added to all transactions that would require a specific pin or additional private key of some sort to be manually added to the transaction comments? Maybe that private key could be set somewhere in Pera wallet? While I understand your comment regarding the SIM hack, there will always be vulnerabilities to every validation method. Requiring a pin sent to an SMS number would have made the MyAlgo attack radically more difficult. It wouldn’t make it impossible to hack a single given wallet or account, given a high enough level of effort - but it would deter widespread attacks that take advantage of a simple “passphrase hack”.
You can use Google authenticator, to avoid this attack vector. That is what Ludovit Scholtz made available. First you get a shared secret by reading a QR code, then generate every 30 seconds a 6 digit number, used as a second factor. See mail.google.com, try it out: set Google Authenticator as second factor.
Contract is public. There is no shared secrect to generate PINs from.
The Google Authenticator has a private, shared secret: shared, because you know it, and the web server /Android app knows it. It is not stored on the blockchain. From this secret you can generate a PIN by using time and the shared secret, a d the web server/app can generate a PIN. Then the server/app can compare the PIN it comkputed to the PIN you enetered. Try it out at mail.google.com
Hmm… it works for me…
@Maugli
I was referring to SMS 2FA.
I am not quite sure what you mean by implying I am not familiar with authenticator apps.
@FrankS But I tagged you here, to ask if you want to help with multisig in C# SDK… So far I have Algorand2FAMultisig/MsigExtension.cs at master · scholtz/Algorand2FAMultisig · GitHub but it may have some tuning…
If you insist on trolling, I’ll ask for you to be kicked. If your misquote was intentional, you should be aware that I may consider that defamatory.
I’m just trying to think through how there could be an additional layer of security - optionally - that would secure all outbound transactions from a wallet.
I understand. I think your intentions are admirable. I’d be happy to continue thinking about this with you.
First, where would you like to see the “additional security” be implemented and why?
You did mention Pera. But you also mentioned MyAlgo web wallets.
Sorry Frank, i did not mean to insult you if you feel that way.
I really hoped for cooperation. Multisig is one of the best algorand inventions and i believe it should be used.
What do you think of this 3 multisig setup? One account cold storage, second account hot storage, third account protected by 2FA?
1 Like
Maybe we could do a Teams/Zoom call to discuss further? I don’t think we need to be concerned in the least bit about MyAlgo per se. The only thing we should be concerned about is securing wallets in Pera. The account we had that got hacked was created in Pera, and then someone must have connected it to MyAlgo using the recovery passphrase. That recovery passphrase - I’m not sure if that then gets hashed into a key of some kind - must have been stored somewhere on the browser or in MyAlgo’s systems, and the hackers then had a simple route to steal all the funds. They either used the passphrase itself to recover the wallet somewhere, and then initiated transfers out of it, or they used the hash key if such a thing exists - not sure - and were able to achieve the same result. One way or another, that one set or piece of information was enough to grant full access to the account. How can we prevent this from happening again? I just got shanked out of thousands of Algo in one wallet, and had to quickly remove a bunch more from another, so this will be the first governance period I will have ever missed - in two wallets! I think a technical solution that definitively protects a Pera-created wallet from being recovered by an unauthorized party, or at least the prevents transactions without a secondary security key - would be an admirable response and it would go a long way to differentiating this ecosystem. It is our response to adversity that defines who we are.
There is such a solution already – use a HW wallet.
It would be nice to have a SW solution as well, using 2 out of 3 multisig. But setup is more difficult. That’s where Scholtz, FRankS and others could do a lot.
From my point of view, the story about myAlgo is quite simple. Someone on goDaddy found a bug that you could inject other hostings filesystems. He found that there is hosted the prefered algorand wallet, so injected it with proxy file and when user signed tx, imported mnemonic, or just openned his account routed the decrypted mnemonic to the proxy and received it to his server. Later he swiped all the evidence, waiteed some time, perhaps sold all mnemonics on black market. Then person executed theft on big accounts, later they tried to steal all available assets. They must have had some system to launder the transactions, some favorable cex which they routed it to… Its quite a shame on myAlgo or their auditors that they were on shared infrastructure, but the life goes on… Disclaimer… the reference to the bug on godaddy and myAlgo hosted there was discussed on algo discord, and i cannot confirm if it is true, but it all falls together. If AF still claims that they do not know how this happened, i am asking them to deny that they were hosted on godaddy…
But to the 2FA authentication. I have implemented that service which any wallet can implement. The app is fully open source and runnable by anyone. It is just signator which signs if you provide correct Algorand authentication pin. Do you think it would solve your need for better security? Do you know about algorand multisig feature?
Btw you can rekey the account to multisig, or rekey multisig to standard account, or rekey to standard account protected by ledger…
1 Like
@scholtz I try to repeat your steps, but I get for Algo Wallet
Service realm: 2FA#ARC14
the following error: Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.
Also, where is ARC14 documented?