They are music, sound effects and vibration. You see, for total immersion the device actually vibrates when you crash providing that extra level of realism:P
Forgot to say that you steer the snake by tilting the phone. That's kind of important for the whole experience. There used to be a virtual joystick but I temporarily removed it as I think accelerometer steering is superior choice in this particular game.
Many commenters claim that pastor is not watertight, and that is of course 100% true. I completely agree! There is much room for improvement and I appreciate these comments very much.
However we all have an Achilles heel in our online security management strategies. I'm guessing that master email addresses, used to reset passwords and authenticate and also smartphones are a much much weaker link then a system like pastor, even when it is only used to generate parts of passwords and everything else is written down. Would you continue reading this comment if you suddenly became aware that you had no clue where you phone was and vaguely remembered putting on some counter in some store somewhere? I even had to checked the presence of my phone when writing that. Twice.
Also there are alot of integrated systems for managing passwords. Centralized payed services can of course sport far higher quality assurance, but pastor is a completely self contained script that can be remembered and kept anywhere. By using a simple solution one removes a lot of the pitfalls that are present in more complex solutions. The weaknesses, which are always there in any system, can be more easily understood and managed.
Disregarding security of this particular implementation and trade offs, the problem is that while it's a simple solution, it's not convenient: password managers are more usable. I'm saying this as a guy who wrote similar password generator once, and used it for some time, then switched to a password manager.
When you need to change a password for some website, you'll have to add something to your "door id", e.g. a counter. Then you'll have to remember such counters for every website where you decide to change password. Due to this I was a bit reluctant to change passwords, which is dangerous.
If you want simplicity, the simpler and more convenient solution is to keep an encrypted text file.
--
As for security, the best approach to deterministic password generators I've seen is this:
This is true. I have door ids that with version numbers in them, but then again I store a list of door ids in clear text.
I used to have an encrypted list of passwords, but I was reliant on more complicated software to encrypt and decrypt the password file. Also there was more bookkeeping involved. Whenever I added a password I had to remember to save and encrypt the file and then decrypt it again to verify that I had use the right master password.
Do you think pwclip [1] would work well for you? The key file is optional, if you provide a -c argument that prompts for your passphrase (and ideally returns scrypt(pw)).
You can add a standard string to all passwords, for example "Ab1#", so that it satisfies like 99% of sites. You do get in situations where you have to know remember some more information, but this can mostly be written down.
"You do get in situations where you have to know remember some more information, but this can mostly be written down."
That boils down to "this idea won't work"; "writing down my passwords" is the exact failure case we're trying to get away from. And I don't have that problem with LastPass.
The name of the game isn't to try to make this idea work at all costs. The name of the game is to find the best way to manage passwords. It's important not to lose sight of that in the argument. (If you look around, you'll see this particular cognitive problem come up a lot in engineering... never lose sight of the overall goal no matter how far into the trees you go.)
Unfortunately, at least a dozen iterations of this idea have come to my attention, to say nothing of who-knows how many hundreds or thousands of implementations of this basic idea there are, and they haven't succeeded because they really don't work in the real world.
If I write it down, I will lose it. I do have some passwords that follow a specific pattern that I can remember easily for sites I might need to access outside of having KeePass on a machine (haven't put it on my phone).
I love this idea, I hate having to have a actual database to keep after and secure, and I wish it could be done in a way that wouldn't require that, but sites have too many variables for passwords that for me, literally, this wouldn't work on sites I use every day.
ok, so [email protected]@site.com would be my unique door id, so each site would have a unique hash. that solves the first problem, basically.
if someone compromises that site, they get the unique hash. presumably they're not using an expensive hashing algorithm (most sites don't). since they know my username and the site name, they can start brute forcing my unique hash to determine the password. sure, the program could be using an expensive hash algo that would make this take some time, but the whole point (i thought) was to prevent passwords at rest. with this you still have passwords at rest... they're just distributed out across the internet.
there is benefit here, in that you have to compromise each site to get each unique set of credentials. but the downside is a much bigger single point of failure. you trade off the inherent security of memorized complex passwords for one complex master password and the hope that nobody will ever discover or brute force it.
at the end of the day, passwords are still vulnerable to the same flaw: you only need one attack vector to succeed in compromising accounts. with 2-factor auth you need two attack vectors to succeed, which isn't impossible, but is harder, which is really what security is all about.
If you looked at a random cryptographically secure hash on the internet, would you be able to determine what hashing algorithm was used? Would you know how many rounds it was sent through, or whether any other hashing techniques were used prior to the final hash?
Yes, yes, yes. Password hashes that use salts or rounds are prefixed with said information, either so you know how to decrypt it, or know how to strip away the salt, or know what number of rounds to decrypt to.
So if I did a salted sha256 followed by 8 rounds of bcrypt each with their own unique salt (probably a bad idea and I know it) you would know that I started with sha256? Wouldn't the final round of hashing obscure all previous rounds? And how would you strip away a salt without having the original, unhashed information? The whole point of a salt is to be factored in prior to the hashing process.
Awesome that you like it!