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

101–110 of 113 posts

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

#101

Post by tialaramex »

Jfreegman wrote: post #100
UncleMeat wrote: post #99

Earlier quoted context omitted.

Rainbow tables are a brute force technique.

Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks, hence the distinction. If every user had a unique password, rainbow tables would be rendered useless. This is why it's important to reduce the likelihood that a randomly generated password is comprised of a common pattern.

> Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks

No. All time-space trade-offs need to expend the entire attack effort once (and usually it's considerably more). Their advantages are that you can do this in advance (timeliness) and that you can re-use the product (which is what salt mitigates).

You can very simply increase entropy until the attack effort cannot be deployed at all, regardless of when. For example the 'pass' tool lots of people have mentioned in this thread defaults to 24 character random passwords, far more than 128 bits of entropy. As a result it simply isn't possible to deploy the attack effort even once, you can neither do a Brute Force attack nor build the Rainbow Table to find these passwords.

The way the Rainbow Table got famous is its application to the LM Hash, an old (but already terrible when it shipped) Microsoft password hash. LM Hash uses two 56-bit values to represent a password, naively this looks like 112-bits of entropy but you can attack each independently so it isn't.

Rainbow Tables took attacking this from something that could in theory work on any password but you'd get bored waiting for your "crack" program to finish if it wasn't trivial to a few minutes on a fast laptop for every possible password. Because it's a time-space tradeoff, so somebody put all the effort in once and then you can re-use it.

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

#102

Post by Jfreegman »

tialaramex wrote: post #101
Jfreegman wrote: post #100

Earlier quoted context omitted.

Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks, hence the distinction. If every user had a unique password, rainbow tables would be rendered useless. This is why it's important to reduce the likelihood that a randomly generated password is comprised of a common pattern.

> Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks No. All time-space trade-offs need to expend the entire attack effort once (and usually it's considerably more). Their advantages are that you can do this in advance (timeliness) and that you can re-use the product (which is what salt mitigates). You can very simply increase entropy until the attack effort cannot be deployed…

>No

Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. Therefore entropy in of itself does not necessarily mitigate rainbow table attacks. Entropy does necessarily mitigate naive brute force attacks. We can use this same logic for more reasonably sized passwords that are comprised of known patterns but would otherwise be difficult to brute force.

Obviously you could use extremely long passwords and be fairly certain that you won't end up with something that would be found in a rainbow table or dictionary. You could also just use passwords that are long enough that they can't be brute forced and remove common patterns from the set of possible passwords. Both of these solutions are valid, and both have theoretical weaknesses that are irrelevant in practice.

You've spent a significant amount of time trying to convince me that my random password generator is flawed in some way. Why don't you just demonstrate how instead of continuously trying to argue tangentially related theoretical points? I would hope that such an effort would be motivated by a practical concern and not merely the desire to bikeshed out of boredom.

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

#103

Post by tialaramex »

Jfreegman wrote: post #102
tialaramex wrote: post #101

Earlier quoted context omitted.

> Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks No. All time-space trade-offs need to expend the entire attack effort once (and usually it's considerably more). Their advantages are that you can do this in advance (timeliness) and that you can re-use the product (which is what salt mitigates). You can very simply increase entropy until the attack effort cannot be deployed…

>No Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. Therefore entropy in of itself does not necessarily mitigate rainbow table attacks. Entropy does necessarily mitigate naive brute force attacks. We can use this same logic for more reasonably sized passwords that are comprised of known patterns but would otherwise be difficult to brute…

> 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 result, that you were "certain" to roll snake eyes, you weren't, but it has happened anyway and so now it won't change. Entropy is not a measure of what did happen it's a measure of the unknown. Password generation entropy doesn't result in passwords which change constantly, it just means you can't know what the password might be within that parameter.

Constructing a rainbow table where the choice function just cycles through some number of arbitrary guesses - and then saying if those guesses are right the rainbow worked, therefore rainbow tables were a success skips the step where it's overwhelmingly likely that none match, it fails and was a total waste of resources. Nobody actually does this because it's pointless.

When we tell humans to pick randomly they behave like you, and your algorithm - trying so hard to pick a "non-obvious" answer and thus inadvertently they're predictable. Your algorithm is, as a result, needlessly predictable compared to sane "random password" code and yet also significantly more complicated.

Look at the number line. See the first number you think isn't interesting? Well the fact it's the first non-interesting number is pretty interesting, isn't it? So now maybe that's not the first one that isn't interesting after all. Next one, same argument. Likewise your removal of "common patterns" just means the set of possible passwords is made smaller, and leaves remaining passwords with the "common pattern" of not having those "common patterns". It's futile, stop it.

If you want to put your intuition about what "random" ought to be like, put it into a playlist shuffle codebase or something, where humans will appreciate how properly "random" it feels to always get a nice mix of things. In security software this is a mistake, no matter how sure you are that it's common sense to do it your way.

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

#104

Post by nerdponx »

blackfawn wrote: post #10
animalnewbie wrote: post #3

Sometimes you don't want minimalist- you want to quickly find and visualise things. What I'd love is a Tui "curses" interface to keepassdb with quick vim like navigation. GUI is both too heavy and not too keyboard friendly. In fact, unless there's a specific (and specified) reason, all password managers should be based on the somewhat de facto standard of keepassdb

It's not a TUI but I have used kpcli ( http://kpcli.sourceforge.net/ ) as a method to access keepass databases over SSH and text interfaces. I've thought about building a more TUI-based option but have yet to get around to it.

Is this still being maintained? It's a great idea but the Keepass database format has been evolving (we're on version 4.x now) and I don't want to use unmaintained software to manage my passwords.

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

#105

Post by nerdponx »

xerxesaa wrote: post #91
cycomanic wrote: post #64

I am surprised that keepassxc does not get suggested more often. Uses the probably most common file format, has support for uibikeys, ssh agent and secret service (can act as gnome-keyring/KDE wallet substitute). Those features make it the best password manager for me

Only complaint I have about it is it has no quick unlock feature unless you have a Mac with TouchID. It is really inconvenient to type the master password every time rather than a PIN. I realize there is a security trade off here, but I think it's well worth it.

FWIW this is a limitation of KeepassXC itself and not the database format.

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

#106

Post by UncleMeat »

Jfreegman wrote: post #102
tialaramex wrote: post #101

Earlier quoted context omitted.

> Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks No. All time-space trade-offs need to expend the entire attack effort once (and usually it's considerably more). Their advantages are that you can do this in advance (timeliness) and that you can re-use the product (which is what salt mitigates). You can very simply increase entropy until the attack effort cannot be deployed…

>No Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. Therefore entropy in of itself does not necessarily mitigate rainbow table attacks. Entropy does necessarily mitigate naive brute force attacks. We can use this same logic for more reasonably sized passwords that are comprised of known patterns but would otherwise be difficult to brute…

> For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor.

But it doesn't. You seem to be taking it as gospel that this sort of password is going to show up in the early in the list of passwords people are trying. But I don't buy it. There is no need to reject a long password that contains some repeated characters.

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

#107

Post by 101101001010 »

emptysongglass wrote: post #97
101101001010 wrote: post #89

Earlier quoted context omitted.

That's great to hear! I've been a long time user and never had a single issue with it. Autofill would be great! Do you know why the Play Store description says that it is no longer maintained? Is the app being published somewhere else?

I don't see that anywhere in the description? Last update shows March 20th. Listing I'm look at is https://play.google.com/store/apps/details?id=dev.msfjarvis....

Huh, it appears that the app in the link I shared above it's the legacy version and this should be the new one (guessing from the age of each app).

Thanks for the info

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

#108

Post by Jfreegman »

tialaramex wrote: post #103
Jfreegman wrote: post #102

Earlier quoted context omitted.

>No Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. Therefore entropy in of itself does not necessarily mitigate rainbow table attacks. Entropy does necessarily mitigate naive brute force attacks. We can use this same logic for more reasonably sized passwords that are comprised of known patterns but would otherwise be difficult to brute…

> 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, end of discussion. It doesn't matter if the passwords it produces are completely random. That's not the goal and is completely irrelevant. The goal is to produce unique, unpredictable passwords that utilize randomness. We're not producing fixed-length keys. In the average case for web-based logins, uniqueness is far more important than entropy.

So, I'll say it once more. If you can demonstrate how passwords generated by the algorithm I wrote are predictable or otherwise insecure in a real-world setting as you claim, then do it. If you cannot, then any further responses are in vain.

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

#109

Post by Jfreegman »

UncleMeat wrote: post #106
Jfreegman wrote: post #102

Earlier quoted context omitted.

>No Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. Therefore entropy in of itself does not necessarily mitigate rainbow table attacks. Entropy does necessarily mitigate naive brute force attacks. We can use this same logic for more reasonably sized passwords that are comprised of known patterns but would otherwise be difficult to brute…

> For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. But it doesn't. You seem to be taking it as gospel that this sort of password is going to show up in the early in the list of passwords people are trying. But I don't buy it. There is no need to reject a long password that contains some repeated characters.

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.

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

#110

Post by UncleMeat »

Jfreegman wrote: post #109
UncleMeat wrote: post #106

Earlier quoted context omitted.

> For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. But it doesn't. You seem to be taking it as gospel that this sort of password is going to show up in the early in the list of passwords people are trying. But I don't buy it. There is no need to reject a long password that contains some repeated characters.

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.

Post reply on HN