91–100 of 185 posts
This doesn't address the key issue of how many "in head" horcruxes you want to have. Is it one and the same for all passwords? Then two broken passwords reveals it (if someone's clever maybe even 1, not sure here). If it's different for different passwords, you now need to memorize (or store elsewhere) a list of many, many such horcruxes. Not 7... but maybe a 100 or 200 to be practical for a heavy user of internet ap…
It is much better to use a password manager than trying to remember poorly crafted passwords in your head. But also really/truly remember not to really put all your eggs in one proverbial basket. Password managers are not without dangers: 1. If you forget your master password or secret key (you need both to setup a new device), you are screwed. 2. If the password manager cloud sync service (like 1password) decides to…
Earlier quoted context omitted.
I think I really disagree with you there. This is the same concept but applied client-side instead of server-side. But “client-side peppering” won’t get you to the front page of HN..
I would click “client-side peppering” over horxsomething, didn't read Harry Potter
I wrote a program to generate passwords based on user input about 10 years ago. I still use it today and a few teams I have worked with still use it. I called it DPG. Deterministic Password Generator. It is a similar concept. I have implemented it in Go, C++, Java and Python. I wish the idea of generating passwords when needed rather than storing and retrieving them was more popular. Traditional password Managers are…
This doesn't address the key issue of how many "in head" horcruxes you want to have. Is it one and the same for all passwords? Then two broken passwords reveals it (if someone's clever maybe even 1, not sure here). If it's different for different passwords, you now need to memorize (or store elsewhere) a list of many, many such horcruxes. Not 7... but maybe a 100 or 200 to be practical for a heavy user of internet ap…
I wrote a program to generate passwords based on user input about 10 years ago. I still use it today and a few teams I have worked with still use it. I called it DPG. Deterministic Password Generator. It is a similar concept. I have implemented it in Go, C++, Java and Python. I wish the idea of generating passwords when needed rather than storing and retrieving them was more popular. Traditional password Managers are…
The standard answer is that if someone gets hold of your generation procedure, they can guess all your other passwords, and your future passwords too.
Earlier quoted context omitted.
What's an "encrypted random number"? If they have 5 random numbers and XOR them together, then they won't get the key as output.
So then it's not "any" 5 out of 15, it's "any group of these three", which is a significant disadvantage compared to SSS.
Each person is part of 1001 groups and has a separate 256-bit number for each group. To recombine the numbers, each of the 5 needs to select the number corresponding to that group.
I think this works just as well as SSS for small/moderate sized groups. It's a little less elegant because you need to know which group you're participating in at decode-time, and because it's not scalable (but there are few serious applications that need the scalability).
This is not an improvement over just using the click-to-login features of modern password managers. Modern password managers generate strong random passwords and integrate with login forms in your desktop browser and on your mobile device. There are some exceptions with sites or applications that don't behave well, but as a general rule: you should not ever need to know any of your passwords anyway. You should be cli…
Integrating a password manager with a browser is too fragile and risky way of using both. It is best to have them fully separated so they can't communicate. They should communicate exclusively via the user.
The login process should have some friction and should not be fully automated. Adding a secret domain-specific suffix to the password is very little friction for the user a gives obvious benefits: password manager does not know the password, it can't send it to other application (intentionally or by chance), it won't login the user by accident.
Earlier quoted context omitted.
The standard answer is that if someone gets hold of your generation procedure, they can guess all your other passwords, and your future passwords too.
They'd still need your master pass phrase though? So the security is only as flawed as a password manager
Earlier quoted context omitted.
Older and weaker hashing algorithms are probably better for this, sha384 and upwards produce large hashes that might be too big for passwords for some websites. Protonmail trims anything more than 72 characters. See - https://www.reddit.com/r/ProtonMail/comments/khrzhe/pm_ignor...
This isn't good security advice. Taking trunc(32, hex(sha512)) will still give you a result that is stronger cryptographically than taking the 32 characters hex(md5sum) would give you. For more security, you of course can encode the sha512 hash in a format other than hex in order to let those 64 bytes be fewer characters. The hex encoding is only one of many encodings. But the main point is that the solution to needi…
I don't think the algorithm matters here, but only the length.