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

Show me!

All Posts by david eyes

About the Author

Jan 18

A Vulnerabilty which highlights key design difference of passQi

By david eyes | Turning the Qi

Top-tier password manager LastPass (acquired by LogMeIn last Fall) is in the news again as Sean Cassidy, the CTO of Praesidio, outlined a phishing vulnerability of LastPass, as reported here.  It is important to note that there were no reported breaches using this exploit, and that according to reports, LastPass has in part addresses the concerns raised.  Some of the details are very specific to the LastPass implementation, but the essence of the vulnerability lies is the ability of rouge site to trick a user into entering their LastPass master password.  In the worst-case scenario, this can lead to an attacker using the acquired master password to, as Cassidy reports “… download all of the victim’s information from the LastPass API. We can install a backdoor in their account via the emergency contact feature, disable two-factor authentication, add the attacker’s server as a “trusted device”. Anything we want, really”.

passQi’s model is completely different.  Although it automates login and two-factor authentication, it only stores passwords and tokens in the user’s phone, and moreover, never releases them except under the immediate interactive direction of the user.  Any system with an API that can provide unattended access to a user’s credentials, and which moreover, can prompt a user to provide their master password within the target system, will be subject to all manner of exploits.  Passwords are only decrypted from the mobile phone Vault within the Vault itself, based on local (smartphone) authentication by the user, and are only relayed to the target browser with a one-time encryption key that was generated “ad-hoc” on the target machine.  There is no way that a user can compromise their primary vault by actions taken on the browser.

The passQi approach is by design more secure, and represents a next-generation approach to password management.  Although implementations by various vendors will differ, those storing passwords in the cloud are liable to problems of this nature.

Nov 19

Amazon “doubles down” on two-step verification bandwagon!

By david eyes | Turning the Qi

Amazon just launched this week support for two-step verification for logging in to your Amazon account, using so-called “Google Authenticator” style two-step verification as an option (technically referred to as “TOTP” or “time-based one time password,” authentication, along with the alternative option of SMS verification. Amazon has been using the same mechanism for securing their cloud compute platform, Amazon Web Services, for some time now.

Our amazon accounts are of course ones that have a non-trivial transaction risk, since Amazon stores our credit card data and once you have account access, you can ship anything anywhere.  And as a frequently-used site, it is an account which it is tempting to have an “easily remembered” (translation: insecure) password for.

By enabling two-step verification on your Amazon account, you make it impossible for someone to guess or steal your password, as accounts with this advanced security feature require two steps to login: first, the username and password need to be entered, and secondly, a one-time password must be entered.  The one-time password is a number that changes every 30 seconds, and can only be correctly generated by a device running a special application to generate the one-time password.  When you configure the option, you scan a QR code to read a secret value which is used by both your app and the site to generate the one-time password, which is based on a mathematical transformation of the secret and the current time.

That’s the good news.  The less good news is, TOTP typically requires that you store your TOTP secret in a special purpose app (like Google Authenticator).  Which means that, whenever you want to get the number to log in, you need to launch the app and type the TOTP token value – this in addition to remembering/typing the password.

passQi+ changes all that – by not only automating username / password login, but also automating TOTP login.  Like a typical TOTP app, you scan the site-generated QR code, but your do this from within the account details page for your Amazon account in the passQi vault, where your username and password are already stored.  passQi+ then securely stores the secret, and whenever you need to login to your Amazon account, you simply tap the passQi bookmark twice – first on the password login page, and then on the two-step token page that will come up next.  Each time you click the bookmark in your laptop or desktop browser, passQi+ will decrypt the password from the passQi vault on your phone, and generate the current TOTP code for the present instant, and securely relay them to your browser, where they will be decrypted and automatically injected into the login page.

This makes it possible to achieve maximum security for your Amazon account, with minimal hassle!

Having used TOTP on their AWS platform,  it’s not surprising that they did a great job with their implementation – straightforward and easy to configure, plus, they thoughtfully DO NOT automatically set a cookie to bypass two-step verification on so-called “known devices.”  While it is certainly true that a login on device that your have previously logged in on is less likely to used for an unauthorized login, the key word there is “less”.  Recognizing that as currently offered, TOTP is still kind of a pain to use, sites like Google and Facebook default to quickly promoting a previously-used browser to “TOTP not required” status.  But with TOTP so easy with passQi+, shouldn’t you use it all the time?

Screen Shot 2015-11-19 at 11.47.28 AM

… passQi+ users should leave this unchecked!

Although it doesn’t  depict the Amazon consumer configuration and login experience, on our support videos page, there is a quick walkthrough of configuring passQi+ TOTP for AWS service login – the process is more or less the same on the consumer side.

 

 

Jun 15

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

By david eyes | Turning the Qi

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.

Jun 07

Is that a valid gmail account? Just ask Google. What were they thinking?

By david eyes | Turning the Qi

This week I was in what I hoped was final test cycle for the 1.1.2 release of passQi – which includes some nice UI enhancements and important fixes. In the process I encountered what appears to be a significant security flaw in Google’s design.

I had noticed earlier in the week, Google had with some fanfare rolled out their new security center under “My Account.” – “Control, protect, and secure your account, all in one place”. And then mid week during testing, I noticed I was getting passed into the “Detect Login” flow in the app – which means I’m dealing with new, previously unrecognized login urls – and seeing some “unpretty” results.

In the process of figuring out what I was seeing and adapting to it, I learned something the really shocked me. Apparently, in their bid to unify login for all of their web properties, they are requiring the user to enter their full email address, and then on a refreshed version of the page, their password.

Some of you may have noticed when logging in to just about any site, if you enter your password incorrectly, the error message displayed is usually something like “User/Password combination invalid” rathern than “Bad Password.” Why is this? Because an authentication system really shouldn’t be disclosing usernames (especially if those usernames are also email addresses).

Using email addresses in logins when consolidating multiple account silos is handy, insofar as it (more or less) allows you to avoid “namespace collision” – Fred Smith had login “fred” in silo A, while Fred Jones has login “fred” in silo B. One thing you can’t have is two different real world people having the same login.

I actually encountered this problem back when I managed Identity and Profile at Rearden Commerce (now Deem, Inc.) – we had users in different environments and we wanted to create a single login. I’ll just say for now that we solved it differently

Why is this interesting and a problem? Two big reasons: if a hacker is trying to crack a host by brute force attack especially, “leaking” information during a login attempt is not a good thing – if you get a message saying “Bad Password,” that’s basically saying “But the username was good!” You now have verified a username, so you can shift your focus to cracking the password.

Secondly, if you are simply trying to harvest email addresses for spam purposes, you can verify that a given email address is in fact valid.

Go to the Google login page, try to login with a “new” account and enter the gmail address of someone you know. You’ll see that Google will confirm that this is a valid account. (Likewise, if you enter a random spurious email address, Google says that it is not recognized).

Google has lots of clever ideas and technologies in authentication, but this feels like a generically bad move. I’m sure (?) they have throttling and other detection mechanisms in place to lock out pure brute force attempts, but any leakage of data about usernames from an authenticator seems a serious deviation from accepted best practice.

Oh and meanwhile, we did tweak the passQi recognizer to cope better with this type of two-step login, although it will only work smoothly if you click the passQi login from the “enter your password” page – which is where most people will, because of the “remember me” cookie that prompts (or lets you select) possible accounts to login to.

Sep 03

Cloudy Picture: say no to passwords in the cloud in post Jennifer Lawrence, post NSA world

By david eyes | Turning the Qi

The news this week about apparently hundreds of (very) private pictures of celebrities apparently being siphoned from Apple’s iCloud service reminds us again how careful we need to be with what exactly winds up in the cloud.

One might wonder what the pictures were doing there in the first place: sophisticated email users, certainly in the corporate environment, have long understood that you shouldn’t really say anything in an email that you wouldn’t be comfortable if it were read by others than the intended recipients (like: anyone). Likewise this applies to photographs on the internet – especially for “high value” targets.

While the Apple security team will no doubt be double and triple reviewing their practices and procedures, it appears that this breach was some form of targeted attack using perhaps a combination of brute force techniques, social engineering, and possibly, exploitation of “soft spots” in the iCloud infrastructure.

As for email and certain photographs, how much more so for passwords, a “high value” target we call have — encrypted though they may be. We all love the convenience that syncing (and sharing) things through the cloud can give us. However, as detailed in a recent security review of password applications cited by Ars Technica last month,
“Severe” password manager attacks steal digital keys and data en masse
, solutions which store passwords in the cloud are vulnerable to the same kind of breach as in the Jennifer Lawrence situation. Like services such as iCloud, vendors who host passwords in the cloud present a fixed-location target for the determined attack, and once breached, provide access to everything, all in one place.

While security technology will always by an arms race, there are some obvious design approaches that can greatly mitigate the exposure. passQi’s solution, of only storing passwords in the user’s phone while providing the convenience of login automation, moves the “big password treasure trove in the sky” to a much safer remove from hacker exploits. Password information is never persisted in the cloud, and it only transits the internet and passQi infrastructure having first been encrypted by a one time (AES, 256 bit) encryption code which itself has never been presented on any network, using passQi’s secure tethering technology. The user is in complete control of when sessions are created and terminated, and whenever a session-encrypted passsword is relayed out of the phone in response to a login request, this is real-time visible to the user as a smartphone notification.

Jennifer Lawrence and others may have done well to have turned off photostream. Likewise, users who want convenient storage of passwords to turn off products which store them in the cloud.