That's a consequence of the Murphy's law.
You phrased it perfectly for it to have its place at https://courtois.cc/murphy/murphy.html which is full of this kind of stuff. If you read French you might enjoy it.
Military grade when we're talking about a screw is a little different. It means that the screw is made and QC'd to a very specific spec/standard.
My next question might be, "Where can I find you on the FedRamp approved list?". To which, I'm sure they'd respond that anything outside the algorithm is not military grade, which is what most attackers will exploit in the end.
FIPS certified systems can actually be less secure (by design) than non-certified ones
I'm working on an opensource project for Linux users that needs crypto. Needless to say, I'm not an expert in that domain. I was planning to ask experts for help in reviewing the crypto. Your statement makes me slightly nervous. What is the standard procedure to ensure crypto safety in a software project?
Yes. That's the plan. I'm using Rust's crypto libraries. All the code in the application are basically just calls to those libs.
> Apart from that, get audits if you have the means
Unfortunately no. But I got the plan from a crypto forum. I will be seeking their validation when it's done.
To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:
- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?
- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).
- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.
- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)
98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.
And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.
Just because I think it's funny - every time I visit my dad (who's in his 80s) he regales me with his startup ideas. "Why don't you build something that I can put on my glasses so when I lose them I can find them? Whoever invents that would be a billionaire." I say, "Yeah dad, they have that."
"Why don't they make it so I don't have to remember passwords for all these different websites? I could just have one password and it would remember it for everything."
I think I've explained at least a dozen times why I think third party trust is a bad idea; I've had to really refine it down to the level of explaining this to a six year old.
But the salient point here is that even my dad never signed up for LastPass. So who the fuck is signing up for LastPass?
Also techies have been telling non-techies "use a password manager!" for years, and people fail to evaluate one solution or the other.
My brother in law (a non technical person) was telling my wife last year how good LastPass was for him!
ehh. I store my passwords online but its on a file I encrypted offline with strong password (over 20+ characters) and key. I use keepass which is a locally encrypted and stored password manger, and I store the DB on Dropbox and download it to any of my computers/devices were it is decrypted locally when needed. I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you, but my set up seems secure enough to me.
If you have specific questions, feel free to ask.
None of the popular password managers work this way.
so does the family pack
Have a look at [0] - recovery works without 1Password having the master password.
[0] https://1passwordstatic.com/files/security/1password-white-p...
> Recovery Groups One of the most powerful capabilities that a team administrator has is the power to assign members to the team’s Recovery Group. In most configurations the assignment is automatic and Owners, Organizers, and Administrators will automatically be made members of the Recovery Group. In 1Password Families there is no ability to separate the roles of Owner, Administrator, and Recovery Group member; they are all wrapped up as “Organizer.” With 1Password Teams Administrators are given more control, but not all of the underlying flexibility may be exposed to the user.17 17We discovered during our beta testing that it was difficult to make the distinction between Owners, Administrators, vault Managers, and Recovery Group members clear enough for those distinctions to be sufficiently useful. This document describes recovery in terms of the Recovery Group even when the group is not exposed to the Team administrator in those terms.
> Implicit sharing When a vault is created, a copy of the vault key is encrypted with the public key of the Recovery Group. The members of the Recovery Group are able to decrypt the private key of the Recovery Group. Thus from an exclusively cryptographic point of view the members of the Recovery Group have access to all of the vaults. Recovery Group members never have the ability to learn anyone’s account password, Secret Key, Account Unlock Key (AUK), or SRP-𝑥. Recovery is recovery of the vault keys; it is not recovery of account passwords nor Secret Keys.
It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.