Security Design Philosophy

SamuraiSafe was designed with security and simplicity as primary goals.

I believe everyone should use a password manager. And it shouldn't be necessary to pay for a good one.

App Security

Every entry in a SamuraiSafe password store is separately encrypted using the AES algorithm with a 256 bit key, and passwords are only decrypted when required (reducing the availability of cleartext on the device).

Each encrypted object includes a secure hash (HMAC), so corruption of an entry or password is detected (and the impact of any such corruption is limited).

The original core encryption algorithms used in SamuraiSafe are published on github.

Cloud Security

SamuraiSafe can use iCloud (iCloud Drive and iCloud Documents in the Cloud) or manual iTunes sync.

If you use iCloud sync, additional layers of encryption are applied by Apple while the data transits the network and whilst stored on Apple's iCloud servers.

iCloud use is entirely optional, so you maintain complete control over your private information. Your encrypted password safe only resides where you permit it.

A Note On Web Browser Auto-Fill

Many password manager's integrate a web browser with auto filling of the username and password. Unfortunately, doing this is very difficult to implement without introducing security vulnerabilities. There have been several exploits and security issues with various third party implementations (essentially the web browser is tricked into supplying credentials without your intervention or knowledge).

SamuraiSafe takes the simple approach of putting your password or other manually selected private data temporarily in the clipboard. It requires your intervention to paste it into the appropriate fields. The clipboard will then be cleared automatically. If you use drag and drop, a clipboard is also used, however it is cleared immediately after the drop is complete. With iOS 10, the universal clipboard is introduced: the clipboard contents will always remain local to the device.

The new in-built web browser introduced in iOS 9 uses SFSafariViewController which runs as a separate process. So even if the Safari browser is compromised, inter-process memory protection keeps any decrypted private data safe.

A Note On Touch ID and Face ID

Most iOS password managers allow the use of Touch ID/Face ID to authenticate the user to allow opening a password safe. This requires storing credentials (either your private safe key or something based upon it) on the iOS device to allow decrypting your safe. These credentials are further encrypted and quite secure (the private encryption keys remain within the Secure Enclave). The credentials do not leave the device — however this breaks my design principle of not storing or transmitting your private key.

However, adding Touch ID/Face ID has been a popular request – so I have now added the feature. Use is restricted to iOS 9 and later, so I can enforce the strict policy of invalidating stored credentials if any fingerprint/faceprint is added or deleted from the device. Without this policy, anyone who knows the device passcode can add a new fingerprint/faceprint and then Touch ID/Face ID authenticate.

Please note that Touch ID has been compromised with dummy fingerprints. Also, if you jailbreak your device, you disable core protection mechanisms, and the ease of extracting private information from the running application (or one masquerading as it) becomes dramatically easier.