I'll assume that they want to update both the login password hashing difficulty and the vault decryption difficulty. To handle its use as a login password they probably have a table somewhere that contains:Įmail, salt1, hash1(master_password,salt1) I think there might be a way to update it without having to wait for the user to supply the master password, at least if their web login works like most, although it would require some additions to the database and their server side vault storage.Īccording to the documentation I found the master password you create when you make your account is the master for both logging in to your account and for encrypting your vault. So it cannot be done silently in the background.
> Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. People take cybersecurity seriously, and counting on every employee to participate in a coverup of a serious breach is unlikely to go well. Unless it was very recent, this is very unlikely.
These are huge oversights that fundamentally undermine their credibility.Īs far as coverups at other companies go, that would be some coverup to avoid any whistleblowers leaking things. The number of PBKDF2 "rounds" should automatically have increased, even for old users. The entire vault should be encrypted, end to end. Someone who forgot to delete their account from years ago could easily be counted if the company is looking to inflate user counts.Įven if they were 100x the size of the next competitor, they would not get a free pass for the obvious technical failures of their implementation, which have nothing to do with the number of users. Number of users is even harder to pin down since you never know what a company counts as a "user". Since you seem to have sources, it would be nice to see them. 1Password appears to have comparable revenue to LastPass, but it is hard to pin down clear sources.
0 kommentar(er)
