Security Issue - Not best practices

[AdamSC1-ddg]

The changes in this commit (https://github.com/kinecosystem/kinit-ios/commit/0f7a1a24ef8630a0165beda261e66a28e59395e9) seem to suggest that Kinit is using a two-question back-up method for wallet recovery, and only requires a 4 digit answer.

Extensive research suggests that knowledge questions are highly insecure, and are considerably less secure than user selected passwords:

• People who know a target can accurately guess security questions roughly 17% of the time (https://ieeexplore.ieee.org/abstract/document/5207657/?reload=true)

• 37% of users provide fake answers which they then forget. They do this to make them "harder to guess" as they do not feel this method is secure. (https://dl.acm.org/citation.cfm?id=2741691)

• Website passwords are considered weak up until the threshold of 20 bits of entropy. The average security question answer only has, on average, 18.4 bits of entropy as they typically only use letters and have at most one capital letter. This leaves security questions wide open to brute force dictionary attacks. http://homepages.inf.ed.ac.uk/mjust/Trust2009.pdf

• While users are well educated to not share their passwords, they are not educated on the concept of not sharing personal knowledge questions. Things like "What is your mother's maiden name?" seems like a mundane question with no risk to share in a conversation with a social engineer attacker, or even on one's social media profiles.

The industry standard practice for wallet recovery is a 12-word randomly generated seed phrase + an on device 2FA (non-SMS, as SMS based OTP is considered highly insecure https://link.springer.com/chapter/10.1007/978-3-662-54970-4_24).

Kin is likely to be the introduction point for cryptocurrency to many mainstream users. They have a responsibility to protect these users by following industry best practices, both in their own apps and the SDK.

Since cryptocurrency does not have any ability to rollback or reclaim hacked assets, security is a core concern.

This does not address the issue of what the security question process is restoring (as if Kin is keeping a copy of the users private key on a server that is even more alarming), but, the practice of low entropy security questions as a form of recovery authentication is outdated, insecure, and should be replaced.

[fuzzyami]

Adam, I must commend you for your vigilance. Nice to know our codebase is being followed so closely. Your comments are very to the point.

First lets get one thing out of the way: we do not store private keys in the server. Nor do we want to do this at any point as it may imply ownership and carry regulatory implications (note: I'm not a lawyer).

The code you've been looking at does use security questions, but that's really only part of the picture. there are other measures in place that limit an attacker's ability to use our restore procedure. I'd rather not discuss these here right now (although I can assure you that obfuscation and obscuration are not something we use). I will say that in order to use the restore feature, an attacker would also need to have access to the user's email box AND mobile device.

Personally, I feel that 2 questions are too few, even with the other measures. I'm hoping that we can have a dynamic approach and fine-tune the number of questions (but no guarantees there).

We'll be taking your input very seriously. should would want to hear more, please do contact me ami.blonder@kik.com

[AdamSC1-ddg]

Ami,

Thanks for the thoughtful and measured response.

Personally, I feel that 2 questions are too few,

Agreed, but, the more alarming aspect is the low entropy and that questions can easily be answered from knowing the individual, reviewing social media or social engineering attacks.

First lets get one thing out of the way: we do not store private keys in the server. Nor do we want to do this at any point as it may imply ownership and carry regulatory implications (note: I'm not a lawyer).

Great to hear. Can you confirm that you also do not store hashed keys, or hashed seed phrases?

I will say that in order to use the restore feature, an attacker would also need to have access to the user's email box AND mobile device.

FWIW most users use the same recovery questions for their email inbox, and the average user has had their password leaked at least 3 times in plain text dumps (reference: https://haveibeenpwned.com/)

This combined with mobile device spoofing (which can even bypass Firebase) it is a bit alarming.

Looking forward to seeing this security method evolve for recovery, and hope your team is pushing for industry standard security here.

I'll be sure to follow up further by email as I'd love to hear more!

Cheers,

Adam

[natanrolnik]

Oops, sorry for closing and reopening. Thanks for your input, @AdamSC1-ddg. What you say makes sense, but as @fuzzyami said, these are only part of the backup mechanism. We can confirm we are not storing any hashed keys or phrases - these are solely the user's responsibility to do.

[fuzzyami]

@AdamSC1-ddg - and, of course, you're welcome to review the server's repo too. you wont find any private-keys there (hashed or otherwise). we do keep public addresses (but that's legit).

see more here: https://github.com/kinecosystem/kin-app-server/tree/master/kinappserver

[AdamSC1-ddg]

@fuzzyami and @natanrolnik

https://kinecosystem.github.io/kin-ecosystem-sdk-docs/docs/faq-sdk.html

This official FAQ suggests that the private key is indeed stored on a server. Those servers are Google and iOS account servers, which are not exactly secure when we are talking about immutable finance data. Given past breaches (such as celebrity photo hacking from iCloud) and social engineering attempts AND the ability to hijack iOS and Google cloud in phone cloning attacks this seems ill advised.

Can you comment further on the storage of private keys as you mentioned that this was the users responsibility? Was that solely limited to Kinit and not the larger Kin ecosystem?

[fuzzyami]

Hello again Adam, The document you're referring to describes the client SDK. It suggests that the user's private key is indeed kept as part of their personal info on their personal cloud space. I'm reiterating this because I want to make it abundantly clear that we do not have access to our users keys - they're not kept in our servers.

I'm going to let @natanrolnik comment about the security aspects of the client sdk.

[natanrolnik]

Hi @AdamSC1-ddg. As @fuzzyami said, the backup you linked to is not exactly the backup mechanism we are working on these days, but how the private key/seed is stored on the phone. I’ll speak a little bit about iOS, and @yosriz can give you a bit more detailed explanation of the Android implementation.

The KinCore iOS SDK saves the seed in the device’s keychain. I’m not sure how familiar you are with it, but basically, it’s the safest place to store information for an app, and each app only has access to its own keychain (or for apps declared in the same app-group from the same developer).

When backing up a device, the keychain is stored as well, as long as the two conditions below are true: 1 - backup is done via iCloud, or via iTunes with a password. Non-encrypted backups in iTunes do not store keychain data. 2 - the developer may set that an item is stored on that specific device only and should not be ported over with the backup on another device.

Based on that, these are the scenarios I can imagine where the current way the KinCore SDK stores the private key might be vulnerable:

• user makes an encrypted backup on iTunes. His computer is stolen, and the thief has access to both the computer password and the backup password; he manages to decrypt the the backup, and to find in the whole backup file/directories the place where the seed was located.
• the impersonator gets a new/fresh iPhone, manages to login to the victim’s iCloud, and chooses to restore from a backup. Considering this iPhone is not jailbroken (which is not available since iOS 11 and up), he has no way to access the keychain directly. I’m not aware of any way where a backup file might be downloaded from iCloud and inspected on a computer, for example.

Needless to say, users with 2FA enabled in their iCloud accounts significantly lower the chances of being attacked.

I believe that, as with any crypto, the owner must know where are the failure points of the techniques used, and I believe that the solutions we proposed - both by the KinCore SDK and the Kinit app, balance usability and security in a good way.

Please correct me if I’m wrong, I’m interested in hearing what you have to say.

[avi-kik]

I will chime in with a point on Apple's Keychain service. Most users who use the Keychain do so across devices (iCloud Keychain sharing) and store credentials for many financial services, as well as CC information for filling in online shopping forms. While social engineering garnered passwords for some celebrity iCloud accounts, there has never been a security breach of iCloud itself reported. Given the unrecoverable nature of a blockchain account, backup is essential to the user. On Apple platforms, the Keychain is the safest place to store this backup.

[AdamSC1-ddg]

@natanrolnik and @avi-kik - Thanks for the replies. Let me break down my responses:

On Apple platforms, the Keychain is the safest place to store this backup.

The secure enclave is great. The ability to back up credentials with iCloud Keychain sharing is not. There are documented attacks that are a combination of social engineering and brute-forcing that can expose users here. We probably shouldn't discuss that on a public forum though.

While these types of attacks are rare (because of high effort/targeting requirement) they are the kind of attacks far more prominent in crypto because of much higher rewards. It was the same with SMS-based 2FA, people said it was "secure enough" because it often wasn't worth the trouble of breeching, until crypto came along and you have entire criminal rings focused on social engineering to reset phone numbers as well as SIM card spoofing, solely to bypass 2FA.

Most users who use the Keychain do so across devices (iCloud Keychain sharing) and store credentials for many financial services, as well as CC information for filling in online shopping forms.

Agreed. Keychain is sufficient for credit card information, and financial services.

Banks are insured. My money can be reclaimed. Credit cards can be cancelled and rolled back.

None of that is true for crypto. If a wallet is compromised it is wholly compromised, that users assets are gone and neither Kin nor any other asset in crypto is insured by anyone unless using a third-party custody service.

Putting the users key on the server is alarming because the iCloud backups are often only protected by user generated passwords that are usually low entropy.

Storing solely on device with secure enclave and biometric verification (touchID/FaceID) and non-SMS-based 2FA should be the standard.

While social engineering garnered passwords for some celebrity iCloud accounts, there has never been a security breach of iCloud itself reported.

Something never having been breached is not an acceptable threat model. If I open a very insecure bank, then I have never been breached up until the point that I've been robbed.

Further the method of breach doesn't matter. The ability to secure the users assets does.

1 - backup is done via iCloud, or via iTunes with a password

Yes this is a major part of the problem - these passwords are often low-entropy and users often use the same password.

There are other related attack vectors that we can discuss, but, it ultimately comes down to that insecure user password and the keychain being in the backup file.

I believe that, as with any crypto, the owner must know where are the failure points of the techniques used

I agree, but, the average user projected for Kin's ecosystem is not going to be a technical user. Given the challenges that users have with something as simple as passwords for generic account management it should be assumed that users will not know their own failure points.

The standards evolving in the industry (such as with Coinbase Wallet, Brave and Metamask) include:

1. Store keys on local device in secure enclave.
2. Secondary verification with biometric verification (touchID/faceID), if unavailable use a non-sms based 2FA/OTP.
3. Provide 24 (randomly generated high entropy) word seed phrase for users to write down for wallet recovery. With a seed phrase the user can regenerate a wallet which will still contain their assets.

Things that should be avoided:

1. Any backup that puts a private key outside of the physical device.
2. Any system that relies on user selected passwords, words, or codes.
3. Any system using SMS based 2FA.

I get that these techniques are likely overkill, but, if Kin wishes to be the leader in mainstream adoption of cryptocurrency, it is important to go above and beyond in limiting these attack vectors, as attacks are higher in this industry and mainstream users are not yet prepared or educated for managing their own financial assets at this level.

(Once again, I really appreciate the time you guys are taking to engage in thoughtful discussion on this!)

[AdamSC1-ddg]

Provide 24 (randomly generated high entropy) word seed phrase for users to write down for wallet recovery. With a seed phrase the user can regenerate a wallet which will still contain their assets.

Further to this point. For user experience, there is probably a decent way to tie back the users seed phrase to a unique QR code which users in the Kik environment are already well educated on using, and would have an easier time saving.

There are ways to make this user friendly without compromising security.