Already have passQi on your iPhone?
Drag the button on the right, and drop it onto the bookmark bar of your browser -

Show me!

Another Breach at a Major Password Manager Site: Why passQi is different

By david eyes | Turning the Qi

Jun 15

Disclaimer: there is NO such thing as “absolute security” — it is always a question of degree.

LastPass issued a security advisory reporting untoward activity on their network and advising users that those with weak passwords (especially) were at risk and should change their passwords.

This is at least the second time that LastPass has had such an exposure. And here’s why it is likely to be a risk for them and other providers who store encrypted passwords in the cloud, and why a solution like passQi avoids this type of risk.

The short answer is, there are simply some things that are bad to put in a centralized, network accessible place. Especially if the ultimate barrier between your passwords and disclosure of all of your passwords is a single password which can itself be of limited complexity.

By storing all of the passwords in one location, the cost/payoff for a hacker to invest in breaching the network security of the target is high, because once in, they will have access to essentially all (encrypted) password vaults. If these can be captured, they can then be subject to offline cracking, especially if there is a “weakest link” in the security model – simple user passwords.

passQi takes a completely different approach, and though it relays encrypted password payloads through the cloud, it doesn’t store any passwords there – they are stored in each individual user’s own phone, where they are both encrypted in storage, and, most uniquely, encrypted in transit with a one-time AES (Advanced Encryption Standard) key which is known only to the target web page and the phone itself.

When a passQi bridge session is initiated, the user scans a QR code generated by the passQi bookmark, which contains a session identifier (for the bridge session) and an AES key, which is also generated in the browser itself. The session identifier enables the bookmark code to carry on a dialog with the passQi cloud, waiting for a user response; the passQi app also uses this session identifier to relay the password encrypted with the AES key.

The three key distinctions which make the passQi design safer are:

Passwords are only stored in one place, the user’s phone
They are relayed “just in time” – on demand – only at the point at which they are actually needed for login
– The message payload is encrypted with a random strong key that is only known to the code running in the target browser page, and the passQi app (it is not known to the passQi cloud; it transits the network as an opaque, encrypted message).

Finally, passwords are only relayed upon positive command by the user (whenever passQi is in the background).
– User action is required before the encrypted password moves in to the cloud. Even if the passQi cloud infrastructure was compromised, this cannot provide access either to data in transit (because it is encrypted with a key unknown to the cloud infrastructure) or trigger the unintended release of an (encrypted) password message, because user confirmation is needed (when the app is still in the foreground, login is automatically accepted, but with a message).

Note that passQi backups may be stored to a Dropbox account, but they are encrypted by a passphrase whose complexity is enforced (eight words with a minimum average length of three characters), and backups may be deleted from the Dropbox environment once synced to a desktop.

passQi is a mobile centric design where cloud services are strictly intermediaries and not involved in the primary security model. It was designed specifically to avoid the kind of vulnerability just experienced by LastPass, while providing the same convenience of login automation anywhere.