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

91–100 of 113 posts

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

#91

Post by xerxesaa »

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.

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

#92

Post by hanklazard »

forty wrote: post #72
hanklazard wrote: post #53

Earlier quoted context omitted.

I’ve been running it in a docker container plugged into the nginx reverse proxy and letsencrypt companion containers. The latter claims to automatically update certs though I haven’t had it running long enough to test it. Unless you’re set on using Caddy, it’s a pretty straightforward option. Instructions here: https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-compan...

The issue with this kind of solution is that you need to pass your docker socket to the container. Not great.

Can you elaborate on why this is a problem? I'm fairly new to docker (and not a programmer / dev), so I'll take any tips I can get!

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

#93

Post by tialaramex »

Jfreegman wrote: post #87
tialaramex wrote: post #85

Earlier quoted context omitted.

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…

> I can't force users to use reasonably long passwords.

But you can, apparently, force them to use passwords that meet whatever other weird criteria you choose. So this is a statement of policy. You've decided by policy to allow "agkxA1"† but not "V+0mCx&3LmgyC" (because the latter has a "duplicate letter C") and that's crazy.

> Social engineering, dictionary attacks, rainbow tables, password lists, guessing and so on are all much bigger concerns.

Since you enumerated them let's run down the list and actually examine what they are and how your "no duplicate characters" rule addresses them or doesn't.

Social engineering: bad guys persuade the user to give them the secret. Only brick wall UX works well here, so that's WebAuthn / U2F and similar. Your rule makes no difference.

Dictionary attacks: bad guys have a list of passwords to try. Some of those passwords have "duplicate characters" and so are eliminated by your rule. But others do not.

Rainbow tables: it's weird to call out Rainbow tables specifically and suggests you're cargo culting. The Rainbow table is just a very specific optimisation of a time-space tradeoff attack on password hashing (the main thing salt mitigates). Your rule actually makes things marginally easier for attackers in this scenario, again if passwords are short you lose, if they're long enough you don't gain anything.

Password lists: You already listed a dictionary attack. A password list is just a dictionary.

Guessing: Guessing is a brute force attack, the same thing you said was "least effective".

Needlessly making your software more complicated is the way it can lead to practical vulnerability, nobody is going to be able to explain this to your satisfaction and so all I can do is recommend that people avoid it.

Your "add characters from different classes into a pool, then shuffle it to make the password" approach is just slightly worse than actual random long passwords, but the added complexity to make it slightly worse is the problem.

† Actually this isn't allowed, the algorithm actually used insists upon putting at least one character of each class into the password before any others are added. But this far too short password does obey the "No duplicate characters" requirement.

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

#94

Post by Jfreegman »

tialaramex wrote: post #93
Jfreegman wrote: post #87

Earlier quoted context omitted.

>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…

> I can't force users to use reasonably long passwords. But you can, apparently, force them to use passwords that meet whatever other weird criteria you choose. So this is a statement of policy . You've decided by policy to allow "agkxA1"† but not "V+0mCx&3LmgyC" (because the latter has a "duplicate letter C") and that's crazy. > Social engineering, dictionary attacks, rainbow tables, password lists, guessing and so…

>But you can, apparently, force them to use passwords that meet whatever other weird criteria you choose.

No one is forced to use the random password generator, and even if I set a minimum limit they could just chop it up to their liking. All I can do is guide users towards a criteria I think provides the most effective security.

>You've decided by policy to allow "agkxA1"† but not "V+0mCx&3LmgyC" (because the latter has a "duplicate letter C") and that's crazy.

I didn't suggest that all passwords that contain duplicate characters are weak. But if we were to simply use a random string of characters without discrimination, then we would have to allow passwords like "aaaaaaa" and "abcdefg123", which is unacceptable in my opinion. If you agree that there should be some sort of policy that guarantees certain properties, then I'm confused by your position, as that would contradict the main point of your criticism centered around code complexity.

The list of attack vectors was not to suggest that removing duplicate characters was a solution to all of them (I disagree with your assessment but we'll leave that alone for now). I was merely highlighting the fact that brute force attacks are one of the least important factors in securing web-based accounts.

If you are able to point out a concrete example of a vulnerability introduced by disallowing duplicate characters (that includes bugs in the code caused by the added complexity) I'm all ears/eyes. If not, I'm going to call an end to this debate for now. I do appreciate your input though and it's definitely given me something to think about.

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

#95

Post by dnpp123 »

Jfreegman wrote: post #61
dnpp123 wrote: post #30

Earlier quoted context omitted.

Yeah I don't see the advantages of this compared to `pass` as well. The whole source code of bash pass [1] is almost as long as a single header file [2] from this C++ software. Plus pass already handles backup... Minimalist heh. [1] https://git.zx2c4.com/password-store/tree/src/password-store... [2] https://github.com/JFreegman/SpicyPass/blob/master/src/spicy...

The pass source code you linked to is just a wrapper for the unix toolset (and has twice the byte count, not that it matters). Pass has a completely different crypto implementation and security model than SpicyPass. The two are not synonymous, either in features or UX. I elaborated on more of the differences between the two in a different reply to a similar comment. tl;dr different strokes for different folks. I didn…

> just a wrapper for the unix toolset

Yeah, that's the point of using Unix, and why pass is great for that.

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

#96

Post by [deleted] »

thecodrr wrote: post #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.

[deleted]

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

#97

Post by emptysongglass »

101101001010 wrote: post #89
emptysongglass wrote: post #83

Earlier quoted context omitted.

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?

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....

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

#98

Post by forty »

hanklazard wrote: post #92
forty wrote: post #72

Earlier quoted context omitted.

The issue with this kind of solution is that you need to pass your docker socket to the container. Not great.

Can you elaborate on why this is a problem? I'm fairly new to docker (and not a programmer / dev), so I'll take any tips I can get!

It basically ruins most isolation/security benefits containers provide, since having root access to this socket allows to nearly have root access to the host. This is something you want to really avoid.

I don't really have a good solution to this "reload service when certificates are updated" problem that doesn't involve heavier container orchestration.

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

#99

Post by UncleMeat »

Jfreegman wrote: post #87
tialaramex wrote: post #85

Earlier quoted context omitted.

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…

Rainbow tables are a brute force technique.

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

#100

Post by Jfreegman »

UncleMeat wrote: post #99
Jfreegman wrote: post #87

Earlier quoted context omitted.

>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…

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.
Post reply on HN