Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

How secure is Assuming user follows recommended precautions:

  • Don't read along with your finger, or the smudge will tell a thief where your password is.
  • Keep your PasswordCard on your person, don't leave it lying around near your computer.
  • Clear your browser cache and history after printing this page.
share|improve this question

3 Answers 3

I have a quite a few concerns with this service:

  1. The premise of the card is flawed. While it is better than simply writing your password down, it's not much better. If the card is known to an attacker there are 8 x 29 starting places and your choice of length and direction of password. This choice is very likely to be 8 and quite likely to be up-right, right, down-right or down (4 possibilities). An attacker with your card or secret number would likely have your password in 928 attempts. If you consider lengths longer than 8 and directions that go left, multiply that number by the number of possible lengths and/or directions. 8 rows x 29 columns x 8 possible lengths x 8 possible directions still only gives 14848. The card provides very little extra protection than simply writing your password down.
  2. Your card is defined by a secret number. If anyone knows this secret number, they can regenerate the entire card by visiting the site and typing in that number. This number leaks all over the place on the site in question.

    • The site does not default to using SSL, even though the site is available using an SSL connection. Below the card there is a list of options and one of those is "Secure connection". Next to this is a tiny arrow. That arrow is a link to the SSL version of the site. Your secret number will be visible in network traffic if you are not using SSL. There is also a link to the SSL version in the FAQ.
    • The image is pulled in to the page with a URL that includes the secret number.
    • Some pages (such as this one) cause the image to be linked from which causes the image to be sent back with an Expires: header that allows it to be cached for a year. Although they have a precaution to "Clear your browser cache and history after printing this page." this does nothing to prevent intermediate third parties such as your ISP from caching. This is in contradiction to the FAQ which states that only images on the mobile site are cacheable.
    • The secret number is put in a cookie: number:ce9916b2fb16f213 with a very long expiry date.

      Set-Cookie: number=ce9916b2fb16f213;; Expires=Thu, 08-May-2081 13:00:58 GMT; Path=/
    • Both the cached image and the cookie end up on your hard drive, meaning that even if you delete them, they can be recovered unless you use a secure delete process.
    • The site pulls in javascript from several other sources including,, and The FAQ is mostly but not completely consistent with what I see on the site. Note that the domains may also differ, such as and
    • On this page, the Google Analytics javascript in particular caused this request to be sent: number%3D1cc09968cc0f6c31&utmht=1366451569430&utmac=UA-9164771-1&

    • The secret number is written on the card itself. It is much easier to shoulder-surf just that number than the entire card.
  3. The code that generates the secret numbers is available on the site and does use, which is good. Unfortunately I'm not familiar enough with Java to know whether nextLong() automatically seeds the PRNG the same way that nextBytes() does. If the seed for the CSPRNG is predictable, the secret numbers become predictable.

  4. To generate the strings that are used for the passwords, java.util.Random is used with the secret number as the seed. The PRNG used for java.util.Random has serious problems for anything related to security. So much so that non-security-related games developers notice them by accident. The specific problem with this code is that it may introduce patterns in the passwords that would make them more predictable without even knowing the secret key.

In the end, your usage of PasswordCard should be dictated by your risk tolerance. All the above possibilities are unlikely to happen to a random person. If you were the CEO or Sysadmin for a company with some significant value in an industry on China's five year strategic plan, the likelihood of there being an attacker actively trying to get your information is somewhat higher than if we're talking about a high-schooler's Reddit account.

You can mitigate most of the above leakage problems by downloading the Java source code and generating your password card on your own machine.

You can be certain of the seeding by modifying the code to call nextBytes() directly after instantiating the SecureRandom object.

You can mitigate the predictable strings problem by modifying the code to use a second instance of for the password strings rather than java.util.Random.

share|improve this answer
nextLong() is implemented by calling next(32) twice (to get two random 32-bit integers). SecureRandom has its own next() implementation which uses nextBytes(). nextBytes() does automatic seeding from what the underlying OS provides (e.g. /dev/urandom) so that one, at least, is safe. –  Tom Leek Apr 20 '13 at 12:00

Answering the question instead of commenting on Ladadadada's answer as I don't seem to have enough reputation to comment directly (even though I do on stackoverflow; isn't that shared?). Apologies if this is a breach of etiquette!

I'm the author of Thanks, Ladadadada, for your thorough analysis! It's the most thorough I've seen so far. Your points are valid, and I agree with your conclusions. The password card is by no means meant to be iron clad secure, it's only meant to be more secure than the current practice of many people.

I'll address some of the points you mention, such as bringing the FAQ up to date, and reducing unnecessary enabling of caching and setting of cookies. Just to explain one point specifically: the reason the site doesn't default to SSL is that Google Adsense does not work over SSL, and I need the ad revenue to pay for the hosting costs. Not the best of reasons, I admit.

If anyone has questions about me or, let me know. (Probably not here though. What's the accepted way to ask specific questions of someone publicly?)

share|improve this answer
You handle criticism well. That's a very reassuring trait in a developer. I look forward to seeing the improvements. –  Ladadadada Apr 26 '13 at 13:09
+1 for accepting constructive criticism, unlike certain other people. –  Polynomial Apr 26 '13 at 13:18
@Pepijn two options for asking questions - either you could pop into our chat room if you wanted to discuss here (you need 20 rep, which you now have) or you could supply a contact form/suggestion box or the like. We're all friendly in chat :) –  user2213 Apr 26 '13 at 13:19

It's as secure as any other password written down, except these passwords they generate are quite strong.

IF you follow their best practices, you'll be okay...but that is a big IF. You're bound to leave it around. You're bound to get sloppy.

Once you get sloppy, and someone finds is trivial to try all of the passwords on the sheet....

edit : Honestly. I don't see why people don't just memorize a few passwords. How many dang phone numbers did you used to remember before your cell-phone knew all of them? I bet a lot. Use that extra brain-drive space to hold a few passwords.

share|improve this answer
+1, it really isn't that difficult to remember a handful of passwords and some logical variations. In all fairness though, if most systems had the same password requirements it would be easier use the same complex password for each system, which could be a downfall. Maybe that's a good reason why certain systems only allow certain special chars, drives me nuts. –  BigHomie Apr 20 '13 at 1:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.