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

Password Managers

lock.cmpxchg8b.com

Post reply on HN
Print view View original

301–310 of 342 posts

Re: Password Managers

#301

Post by closeneough »

anka-213 wrote: post #271
closeneough wrote: post #232

I would NOT recommend the chrome password manager. If you sync your passwords, they will not be stored encrypted at the google side. You need to specifically set password encryption in the settings. I've also spend a lot of time with understanding password managers in my master thesis. What I can recommend is: https://pfp.works/ The creator was auditing password managers like LastPass, found a lot of issues, and used…

They did the thing that Tavis complained about: "No need to trust us, your data stays on your device (safely encrypted)" You still need to trust that the software is secure.

Yes you need to trust the software. But unless you don't store it on your computer, you need to trust software. The hard part is to figure out which software and whom to trust.

I would definitely use the browser password manager, if I could choose where to sync the data to. I think it's possible with firefox, but it's not straight forward.

I personally trust pfp, because the creator is doing audits of browser addons and publishes them on his blog. They are very well explained.

Also the code is quite compact compared to the other password managers. LastPass, 1Password and Bitwarden have more than 100,000 lines of code, including many third party dependencies. So an audit of PfP is more feasible.

Re: Password Managers

#302

Post by paulryanrogers »

justusthane wrote: post #203
paulryanrogers wrote: post #122

Earlier quoted context omitted.

> 4. Browser support: KeePassXC-Browser. Allows you to autofill your username / password / TOTP from your KeePassXC application to Chrome / Firefox. I believe the point the article is making is that any browser extension to auto fill is inherently insecure for architectural reasons. I find it odd someone so serious about password managers would recommend KeePassX which hasn't seen a release since 2016. Perhaps they m…

> I believe the point the article is making is that any browser extension to auto fill is inherently insecure for architectural reasons. No, that is not what the article said. The article said that password managers that insert elements into the webpage are insecure. You don’t need need to do that to autofill passwords.

Can extensions auto fill without content scripts?

Re: Password Managers

#303

Post by newdude116 »

pnt12 wrote: post #300
indigo945 wrote: post #226

Earlier quoted context omitted.

Yes, but you're not important enough for someone to try your password on other sites by hand, and bots are hopefully not smart enough to do this automatically. You should still use a password manager. Or at least a paper notebook.

Do bots need to do this automatically? What if a programmer gets that database and does a quick search for those naive salts? Then he can do some pattern matching and try the same pattern in some sites like PayPal, Apple, Gmail, etc. Generalize it a bit and you can even create a tool to do this for you for every new database leaked.

He would have to break the cryptographic algo to see the salt. Good luck with that. Sure that is possible for the NSA with weak encryption. But most hackers wont be able to do this. The salt does not give a slightly different hash but a totally different hash. Also, using salt (your own or server based) should protect you from some kind of rainbow table attacks.

But just use a PW manager (e.g. enpass.io ) I am very happy with it but I don't use the autofill plug-ins. You can never be paranoid enough.

Re: Password Managers

#304

Post by jmartrican »

newdude116 wrote: post #303
pnt12 wrote: post #300

Earlier quoted context omitted.

Do bots need to do this automatically? What if a programmer gets that database and does a quick search for those naive salts? Then he can do some pattern matching and try the same pattern in some sites like PayPal, Apple, Gmail, etc. Generalize it a bit and you can even create a tool to do this for you for every new database leaked.

He would have to break the cryptographic algo to see the salt. Good luck with that. Sure that is possible for the NSA with weak encryption. But most hackers wont be able to do this. The salt does not give a slightly different hash but a totally different hash. Also, using salt (your own or server based) should protect you from some kind of rainbow table attacks. But just use a PW manager (e.g. enpass.io ) I am very h…

I think the OP is talking about salts that get concatenated as a prefix or suffix, not the salting that happens in oneway hash functions. Remember the topic here is related to getting your pw's exposed and how to easily create different pw's to deal with that scenario.

Re: Password Managers

#305

Post by novaleaf »

3v1n0 wrote: post #281
RealStickman_ wrote: post #274

Earlier quoted context omitted.

Auto-fill is disable by default and you should not turn it on.

The problem is currently that from an UI POV using the icon to complete is a bit annoying, would probably better if a floating complete icon would be added to the fields when a site is recognized. And that should solve the problem, no?

bitwarden has a right-click context menu, which allows you to fill, or copy username/password. This is easier than the icon, and it doesn't require enabling the autofill feature.

Re: Password Managers

#306

Post by newdude116 »

jmartrican wrote: post #304
newdude116 wrote: post #303

Earlier quoted context omitted.

He would have to break the cryptographic algo to see the salt. Good luck with that. Sure that is possible for the NSA with weak encryption. But most hackers wont be able to do this. The salt does not give a slightly different hash but a totally different hash. Also, using salt (your own or server based) should protect you from some kind of rainbow table attacks. But just use a PW manager (e.g. enpass.io ) I am very h…

I think the OP is talking about salts that get concatenated as a prefix or suffix, not the salting that happens in oneway hash functions. Remember the topic here is related to getting your pw's exposed and how to easily create different pw's to deal with that scenario.

Both. The salting SHOULD happen in one way Hash functions. But sometimes it does not. Using your own prefix when always using the same password is the second worst solution but at least better than nothing. Poor mans salting :-)

Use a PW manager.

Re: Password Managers

#307

Post by tialaramex »

KronisLV wrote: post #299
shandor wrote: post #278

Earlier quoted context omitted.

Everything you described is still a shared secret. Hashing your password client side is just a way to create a random, shared password. Yes, an attacker has a much harder time getting to your password, but they don't need to if it's the hash that's the one the server knows and checks against. Asymmetric cryptography with its Math Magic IS the solution industry came up with.

But if the valid hash changes as a function of time (e.g. a time based salt value), does it still matter as much, then? If a stale hash is stolen, then it doesn't allow to log in since it's no longer valid, nor does it allow figuring out the original password. I find it interesting to reason about all of the interesting ways this could still break, as long as the words of Eoin Woods [1] are followed: "Never invent se…

> why aren't certificates the default way to sign up for sites for end users?

Some reasons:

Initially this doesn't make any sense. Tim's toy hypermedia system (the Web) does not have any of the properties you expect today, it doesn't achieve Confidentiality, nor Integrity, nor Authentication. So it's like you live in a village where they don't have doors yet and you're wondering why there's no locksmith.

Once it did exist the UX for client TLS certificates in browsers is very bad. But of course we could in principle improve that UX.

However an underlying reason is that this approach has lousy privacy properties. Certificates tie an identity to the key, and the Certificate Authority - whoever that would be in this setup - needs to be able to verify those identities or else you aren't Certifying anything. So now maybe you're giving Facebook an X.509 certificate with your full legal name, place of birth, and so on. Most people are not comfortable with that. Even those people who are cool with giving Facebook their real personal details may not be keen to share them also with Google, Twitter, Porn Hub and their favourite web comic.

This is why FIDO tokens used for WebAuthn give a completely fresh random ID and key for each enrollment. Who am I? I'm definitely the exact same person I was when I enrolled here, and more than that I shouldn't need to prove. You can't tie these identifiers and keys to other accounts on other services or even to other accounts on the same service.

Re: Password Managers

#308

Post by mimimi31 »

Wowfunhappy wrote: post #291
mimimi31 wrote: post #240

Earlier quoted context omitted.

This obviously depends on your OS and setup, but on Linux + Xorg at least I don't need root access to do any of the things I listed.

Sorry, I must have been very tired last night. This morning, I can't remember (or figure out) which actions I was thinking of when I wrote that. The only one that still jumps out to me is browser extensions—I'm pretty sure none of the major browsers allow that without user approval within the browser. You'd have to do something nasty which would require root.

>The only one that still jumps out to me is browser extensions—I'm pretty sure none of the major browsers allow that without user approval within the browser. You'd have to do something nasty which would require root.

I've admittedly never tried it, but as far as I understand, installing an extension in Firefox just involves copying the corresponding .xpi file to the profile folder (which is owned by the user, not root) and modifying a few configuration files (e.g. extensions.json). I don't see why some other program wouldn't be able to do that.

If root access were required, you'd have to supply your root password every time you wanted to install an extension.

Re: Password Managers

#309

Post by akvadrako »

jeroenhd wrote: post #285
PufPufPuf wrote: post #251

I use Bitwarden, and to my knowledge the issue raised in this article does not apply to it -- all interaction is through the extension's icon, with no UI elements injected into the page itself. Combined with being completely open-source (including backend), full-featured even in the free version, and $10/year pro version (with features like sharing, encrypted storage, etc.), I can recommend it to practically anyone.

BW has had other issues before. For example, it tends to send your credentials with basic auth requests without your knowledge and without a setting to turn it off. The code executed in your browser can also be manipulated to exfiltrate your entire password store once you unlock it if someone gains access to whatever account Bitwarden uses to publish their addon. Bitwarden is certainly one of the better password mana…

> BW has had other issues before. For example, it tends to send your credentials with basic auth requests without your knowledge and without a setting to turn it off.

This isn't true - I use BW and annoyingly it doesn't work with Basic Auth at all. This is because I have disabled auto-fill.

Re: Password Managers

#310

Post by akvadrako »

3v1n0 wrote: post #281
RealStickman_ wrote: post #274

Earlier quoted context omitted.

Auto-fill is disable by default and you should not turn it on.

The problem is currently that from an UI POV using the icon to complete is a bit annoying, would probably better if a floating complete icon would be added to the fields when a site is recognized. And that should solve the problem, no?

Use can also just use the ^⇧L shortcut.
Post reply on HN