• The biggest issue is they are storing the seed and using the seed to generate OTP for every transaction. See https://bitbucket.org/teamtimeless/timeless-wallet/src/b04553ab442ec46304cee5d160560655dd9ed97a/Timeless-wallet/Network Layer/APIs/OneWallet/OneWalletService.swift#lines-1085. It is a security risk, since many iOS components (such as video player) have memory exploits or arbitary code execution issues from time to time. See the latest security patch by Apple at https://support.apple.com/en-gb/HT213182 . Ideally the seed should be sealed off and never accessed by the app or loaded in its memory. Only the OS should access it and use it to generate OTP.

1Wallet Response:

Not only do users rely on us for security, they also rely on us to create a great user experience. It is a juggling act of UX and security. A well-designed and frictionless experience can make a huge impact on user conversion rates and on the overall usability of the application. And while sometimes it is necessary to sacrifice the ideal UX in order to guarantee the security of our users, it’s a trade-off that we make consciously and with a great deal of consideration and collaboration.

On this note, our decision to proceed with a better UX by making OTP “invisible” and easy for the user by generating the OTP ourselves without user intervention, was not made in vacuum unilaterally; instead, it was done in close discussion with Aaron Li after considering both the Google Authenticator and the iOS15’s new iCloud Keychain based OTP. The choice between making OTP invisible to the user and requiring authenticator OTP input from the user, is a mutually exclusive, binary decision.

By disallowing any transactions to execute without the OTP code makes for a friction-filled and simply, a bad UX. Plus, the physical and logical separation of the “online computer” from the air-gapped OTP device of a web wallet, aren’t as relevant on mobile since the MFA device (i.e., google authenticator) resides on the same mobile device as the mobile application itself. As such, we’d argue that it doesn’t offer the same “air-gapped security” as it would on a web app where the OTP and the webapp are separated. Not only does it not provide meaningful security, we’d argue that it may even be unsafe as we cannot reasonably expect any security for a user whose device that contains OTP is compromised.

Other notes:

In re: to the comment re: memory exploits, we will encrypt all the OTPs and store them in local DB upon wallet creation, and only fetch the correct OTP for the current transaction - the OTP will need to be decrypted first using secure enclave.

In re: the Aaron Li’s suggestion re: using iOS15 Keychain based OTP, this is an even more cumbersome and abstruse process involving many hoops (keychain access, OTP setup for the username+password entry) that a reasonable user may not know or be willing to carry out. Not only that, there’s also a limitation that these MFA devices (Keychain, Google Authenticator, etc.) don’t allow for generating codes in advance.

• A less pressing issue is the implementation is missing innerCores (introduced in v15), which are needed for sensitive operations (reset spending limit up to historical limit, renew wallet life, add new authenticator code, upgrade-without-recovery-address). There may be more sensitive operations in later versions. This version still allows the all operations except the first to be done without innerCores, so it is fine for now.

1Wallet Response: ack. What’s the current plan and the ETC for the “sensitive operations” mentioned that’ll require innerCores to function properly? We can better assess once we understand the scope and the timeline

• Another issue is when innerCores are used, the effectiveTime (t0) of the wallet should also be aligned to beginning of 180-second intervals. Right now it is not, which may introduce problems when they add innerCores.

1Wallet Response: ack. we’ll account for this if and when we intro innerCores

• Google Authenticator is not used at all, hence not two-factor, per SmartOTP paper.

Atlassian

https://bitbucket.org/teamtimeless/timeless-wallet/src/develop/Timeless-wallet/Crypto/MerkleTree.swift

Response