Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SpicyPass – A free and open-source minimalist password manager

github.com

Post reply on HN
Print view View original

111–113 of 113 posts

Re: Show HN: SpicyPass – A free and open-source minimalist password manager

#111

Post by Jfreegman »

UncleMeat wrote: post #110
Jfreegman wrote: post #109

Earlier quoted context omitted.

Why doesn't it? If that password became public knowledge, then it certainly does exist in lists and tables. Its high entropy is only protective as long as it remains secret. This is why it's important to avoid common patterns, even if those patterns are a result of a random number generator.

Every password that becomes public knowledge ends up in credential stuffing lists, whether it matches your password policy or not. "Common patterns" and "passwords that contain repeated characters" are not even remotely the same thing.

>Every password that becomes public knowledge ends up in credential stuffing lists, whether it matches your password policy or not.

That's right. And we don't want to produce passwords that are likely to be on those lists. A simple policy greatly reduces the chances of that happening. After a certain number of zeros, entropy is no longer a concern.

>"Common patterns" and "passwords that contain repeated characters" are not even remotely the same thing.

I've already addressed this.

Re: Show HN: SpicyPass – A free and open-source minimalist password manager

#112

Post by woadwarrior01 »

munchbunny wrote: post #71
woadwarrior01 wrote: post #62

Earlier quoted context omitted.

Not true. The solution I described would survive a local machine compromise (the GPG key is maintained on the Yubikey), the 1Password based solution won’t. How could generic malware steal secrets that are not even on the device? Furthermore, pass encrypts each password separately (I.e GPG generates a new symmetric key for each password). In case of 1password, if the master password is compromised, it’s game over. Als…

Your solution doesn't survive a real-time attack on a local machine compromise (wait for you to enter the PIN and then opportunistically use the private key). It only makes doing so harder by automatically re-locking the key. That said, your system is well past the point of "password storage is no longer the most economical surface to attack".

Occasionally entering the PIN + Physical touch on the Yubikey for every decryption call. Since the private key never leaves the Yubikey, every decryption needs a physical touch.

Re: Show HN: SpicyPass – A free and open-source minimalist password manager

#113

Post by tialaramex »

Jfreegman wrote: post #108
tialaramex wrote: post #103

Earlier quoted context omitted.

> Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. This muddle reflects your overall intuitive mistake. When you roll two fair dice the "snake eyes" (two ones) outcome has only one chance in thirty six. But if you've just rolled snake eyes, the probabily it was snake eyes isn't one in thirty six it's 1.0 exactly. We do not say, as a resul…

You missed my point again, and your tangent on randomness is unnecessary; I have no misconceptions of how randomness works, and it is precisely that understanding that has lead me to these decisions - a pure random password generator produces every word in the English language. That's not a good thing! The point remains that if your password generator produces passwords such as "aaaaaaa" then it is a bad algorithm, e…

> The point remains that if your password generator produces passwords such as "aaaaaaa" then it is a bad algorithm, end of discussion.

The correct algorithm does this, and you've managed to convince yourself that this is bad and it's time to invoke lots more complicated code. This is the end of the discussion in the sense that you've departed from reality so severely that you may be unable to recover.

Here's how zxc24's 'pass' does it:

  read -r -n $length pass
For those who can't read shell that's saying to run the random data from the OS kernel through a pipeline which removes everything except $characters and then consume $length bytes of the result as the new password.

This absolutely can give you "aaaaaaa" as a password if you've unaccountably chosen to use such short passwords - but no more easily than it might choose "fuckwit" or "X3_$mwK" or any other sequence of permitted symbols.

But enough about how to do this correctly, you're very focused on your bizarre way to pick "unique, unpredictable passwords that utilize randomness", so let's look at that again:

The tight inner loop picks characters randomly using code from Sodium. Unfortunately it discards characters from the candidate list once it has picked them, and then it has a further rule which may ignore this (already discarded) character and go round again.

For the short case (size = 4) this means it can produce only about 5.2 million different passwords, whereas a better (simpler) solution gives 78 million different passwords, you've made it more than a decimal order of magnitude worse.

Post reply on HN