I've been working on an idea for a stateless password manager, inspired by this blog post. I'm using a in-browser pseudo-random number generator (seedrandom.js) seeded with a user's master password to create a unique (?) 26x26 tabula recta of characters. The user then chooses a starting point for each website and follows a chosen pattern across the grid to create/access their passwords.

Seedrandom.js uses the RC4 (RC4-drop[256]) stream cipher, which I don't think is considered secure for encrypting information anymore. Q1: Does this matter if I'm only using it as the source of randomness for a 26x26 grid of characters that won't ever pass over a network (everything is generated client side in the browser)?

Q2: Also, what's your analysis of the strength of this system against an attack, both before and after the master password for a user's grid has been exposed? This previous question talks about possible attacks on a tabula recta, but answers focus mainly on keeping the physical token safe, which doesn't apply here.

These are my back of the envelope calculations:

Before master password is known, guessing a 16 character password:

log_2(88^16) = ~103 bits of entropy, which will take a very long time to crack in any context.

After master password is known, brute forcing a password from the grid:

(26*26 cells) * (20 common patterns) * (8 pattern directions, including diagonals) * (20 potential password lengths, 10-30chars) = ~2 million options

So on average this would take about 2 million/2 = 1 million guesses to crack. Depending on the context, this would be cracked in anywhere from ~400 days (rate limited web form, 100 guesses/hr) to << 1 second (database leak, fast hashing algorithm, 1e10 guesses/second).

There's a basic demo of this project here.


Your system would probably work in theory, but seems significantly flawed in practice. There are several practical weaknesses in the way it will be used:

  1. You don't describe how you will convert the master password to the seed for the RNG. This is potentially a weak point.
  2. You haven't specified how users will associate a starting point with a particular site. Without a way to save this, it will be impossible to use. Depending on a user's memory will lead to password reuse.
  3. Users will tend to pick the same or a small number of starting points in the tabula recta based on human tendency, significantly reducing your entropy.
  4. A tabula recta involves more manual work than users will actually want to use in practice.
  5. RC4 has biases in the initial keystream. If this is not corrected for in your RNG, this will insert biases into your tabula recta.
  6. You do not provide a good way for users to rotate passwords other than picking a new starting point for that site. Combined with #2, this will make it even harder for users to remember the starting point for a given site.
  • 1. The master password is used directly as the seed (Math.seedrandom(masterpass)). 2-4. I have a prototype that suggests starting at e.g. grid location [A,N] for amazon, but having an ambiguous starting point is partially a feature to weaken brute force attacks. I did automate a few patterns to reduce the work involved, but this also reduces security. 5. I'd definitely be interested in how to reduce the biases, as I don't think seedrandom.js does. – pst0102 Jan 25 '18 at 2:49
  • Looking at the internals of seedrandom.js a little, the seed I pass in is modified before being passed to RC4-drop[256], which might help address at least one of the biases in the original algorithm. – pst0102 Jan 25 '18 at 4:44

a 26x26 grid of characters that won't ever pass over a network

This is not entirely true. Every password exposes a little bit of this grid. If the attacker obtains one password he has a part of your grid and can use that to try to brute-force your master password.

To make brute-forcing the master password harder you could use a key derivation function such as PBKDF2, so that the grid is based on seedrandom(pbkdf2(master_password)). This slows down brute-force attacks and makes any insecurities in RC4 irrelevant.

  • Interesting, this does seem plausible, especially if the user has a weak master password, although I'm not sure how to put numbers to the problem to estimate the risk. I'll see if I can find a JS implementation of pbkdf2. – pst0102 Jan 25 '18 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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