Live data from Hacker News

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

github.com

81–90 of 113 posts

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

#81
post #73

Earlier quoted context omitted.

Third party browser extensions (and cloud syncing) are two things that, while convenient, create potential security holes. I opted for security over convenience with spicypass. I absolutely understand why this might turn some people off, maybe even most people. But I know that there are people (like me) who want something that isn't connected to the cloud, and isn't going to inherit all of the security flaws of their…

Not having a browser extension is also a security risk, because copy/pasting is error prone, and does not protect you from phishing - which is more of a risk than someone taking control your computer and bruteforcing your vault IMO (of course your threat model might be different from most users, for example if you store passwords not for the web) (Disclosure: I work for a commercial password manager that do offer bro…

[deleted]

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

#82
post #73

Earlier quoted context omitted.

Third party browser extensions (and cloud syncing) are two things that, while convenient, create potential security holes. I opted for security over convenience with spicypass. I absolutely understand why this might turn some people off, maybe even most people. But I know that there are people (like me) who want something that isn't connected to the cloud, and isn't going to inherit all of the security flaws of their…

Not having a browser extension is also a security risk, because copy/pasting is error prone, and does not protect you from phishing - which is more of a risk than someone taking control your computer and bruteforcing your vault IMO (of course your threat model might be different from most users, for example if you store passwords not for the web) (Disclosure: I work for a commercial password manager that do offer bro…

I agree that there are risks either way, though like you said, the threat model is a bit different. SpicyPass isn't explicitly for web passwords. It's just a generalized key value store with added security. I use it to store my bitcoin keys for example, and that's probably not something you want to expose to the cloud and/or your browser.

With that said I don't rule anything out for the future.

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

#83

Earlier quoted context omitted.

Is there a decent pass integration with Android?

There is Password Store[0] although apparently no longer maintained (currently still using it). The downside is that there's no auto-fill etc. meaning that you have to copy and paste every login manually. [0] https://play.google.com/store/apps/details?id=com.zeapo.pwds...

Password Store is still being developed. Master was recently updated to support Android's Autofill.

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

#84

Earlier quoted context omitted.

I've also experienced some difficulties with getting pass to play nicely with gpg, but the hassle was definitely worth it. An integrated pass and gpg setup allows for a single consistent means of authenticating and comes with the idle timeouts that you mention. When I want to push to a git repo and authenticate with my private key, I just run git push normally, and a pin-entry prompt comes up, and I just need to ente…

Often it just comes down to personal preference. A necessary feature to one person is bloat to another. Git integration for example is not something that meets my criteria for a necessary feature of a password store (think non-developers), although I can certainly understand why some people might love it.

Git integration was a major plus point for me. Undo is a basic desire everywhere, and revision control with Git gets you Undo. You get a bunch of other things from Git, but being able to Undo my inevitable mistakes is essential.

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

#85
post #69

Why does the string random_password(unsigned int size) function have "no duplicate characters" as a requirement? Seems to me that this would only reduce the entropy; what does it bring? I need access to passwords from my phone so I'll stick with KeePassXC, but nice project! This makes me want to play around with lib-sodium, the API looks nice.

That's a great question, and I wish I was good enough at math to give you a sophisticated answer. But my thinking is that the entropy you might gain by allowing duplicates is negated by the huge set of weak/guessable passwords you allow. For example, the password "aaaaA1!" is probably more likely to be guessed or used by others than "agkxA1!". (I just checked on haveibeenpwned.com, and the former has been seen 12 tim…

No, your intuition is bad.

If you use passwords of a small enough size that this would really be a problem (like four digit PINs or your "aaaaA1!" example) then your password isn't delivering adequate security against brute force and so you've definitely lost.

If you use passwords that are big enough to make brute force impractical anyway then this "feature" will never make any real difference and is just a waste of time at best, and since it adds complexity it's another place to hide bugs.

Having a PwnedPasswords check (not this silly "repeating characters" test) makes sense if you allow users to enter passwords. Whereas if you generate passwords of decent length and at random then they're random so there's no purpose in checking them.

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

#86
Yet another password manager. But then...why not? Looks simple enough, works mostly well and is good security-wise. I might try it but the only feature that puts me off is password syncing. Minimalist is fine and all but...come on; most people nowadays use multiple devices and password syncing is very important. In any case, nice project.

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

#87

Earlier quoted context omitted.

That's a great question, and I wish I was good enough at math to give you a sophisticated answer. But my thinking is that the entropy you might gain by allowing duplicates is negated by the huge set of weak/guessable passwords you allow. For example, the password "aaaaA1!" is probably more likely to be guessed or used by others than "agkxA1!". (I just checked on haveibeenpwned.com, and the former has been seen 12 tim…

No, your intuition is bad. If you use passwords of a small enough size that this would really be a problem (like four digit PINs or your "aaaaA1!" example) then your password isn't delivering adequate security against brute force and so you've definitely lost. If you use passwords that are big enough to make brute force impractical anyway then this "feature" will never make any real difference and is just a waste of…

>If you use passwords of a small enough size that this would really be a problem (like four digit PINs or your "aaaaA1!" example) then your password isn't delivering adequate security against brute force and so you've definitely lost.

I can't force users to use reasonably long passwords. In the case that they don't (and some certainly won't), it's preferable that their password is still as good as it can be given the length.

When it comes to web logins, brute force is probably the least effective method of attack. Social engineering, dictionary attacks, rainbow tables, password lists, guessing and so on are all much bigger concerns. It's my thinking that most of those threats are better addressed by sacrificing a negligible amount of entropy and removing a large subset of weak passwords.

Moreover, this reduction in entropy only applies when the attacker knows the algorithm used to derive the password, making it even less relevant for the average case. (That's not an appeal to security through obscurity; just an observation).

>Whereas if you generate passwords of decent length and at random then they're random so there's no purpose in checking them.

Random != secure. "aaaaaaaaaa" could be the result of a random function. The goal is to create passwords that are both difficult to brute force, and difficult to guess, while making no assumptions about the length.

Entropy has diminishing returns; if it takes 10 million years to crack a password, another 5 million doesn't increase security. However I would re-consider if someone could provide a concrete example of how the small loss in entropy could lead to a practical vulnerability.

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

#88

Earlier quoted context omitted.

Interesting. Just 2 questions, is there a way to sync it run on Android. Got nextcloud instance. Nice if it can do that. Since there are password I would need on the move.

I just store my database on Dropbox and use keepassdb on android.

Can you link to the app

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

#89

Earlier quoted context omitted.

There is Password Store[0] although apparently no longer maintained (currently still using it). The downside is that there's no auto-fill etc. meaning that you have to copy and paste every login manually. [0] https://play.google.com/store/apps/details?id=com.zeapo.pwds...

Password Store is still being developed. Master was recently updated to support Android's Autofill.

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?

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

#90
post #69

Why does the string random_password(unsigned int size) function have "no duplicate characters" as a requirement? Seems to me that this would only reduce the entropy; what does it bring? I need access to passwords from my phone so I'll stick with KeePassXC, but nice project! This makes me want to play around with lib-sodium, the API looks nice.

That's a great question, and I wish I was good enough at math to give you a sophisticated answer. But my thinking is that the entropy you might gain by allowing duplicates is negated by the huge set of weak/guessable passwords you allow. For example, the password "aaaaA1!" is probably more likely to be guessed or used by others than "agkxA1!". (I just checked on haveibeenpwned.com, and the former has been seen 12 tim…

Small correction: the password that has been seen 12 times is "aaaaA1" (no ! char). But "agkxA1" has still been seen 0 times.
Post reply on HN