5 ms·

It used to mean "use AES instead of rolling your own form of symmetric encryption." Then it became "use a library for AES instead of writing the code." It has n

It used to mean "use AES instead of rolling your own form of symmetric encryption." Then it became "use a library for AES instead of writing the code." It has now reached the obvious conclusion of "don't do anything vaguely security-related at all unless you are an expert."

tptacek 2y ago
No it hasn't. The subtext of "don't roll your own crypto" is that "AES" doesn't do, by itself, what most developers think it does; there's a whole literature of how to make AES do anything but transform 16 unstructured bytes into 16 different bytes indistinguishable from random noise; anything past that, including getting AES to encrypt a string, is literally outside of AES's scope. The shorter way of saying this is that you should not use libraries that expose "AES", but instead things like Sodium that expose "boxes" --- and, if you need to do things that Sodium doesn't directly expose, you need an expert. Contra what other people on this thread have suggested, reasonable security engineers do not in fact believe that ordinary developers aren't qualified to build their own password forms or permissions systems; that's a straw man argument.
- pclmulqdq 2y ago
  Reasonable security engineers take a reasonable position on this. Many other developers (usually uninformed ones) believe this now means "don't make an auth system." Like it or not, this has become a sort of adage that people cargo-cult.
  - tptacek 2y ago
    If you can't keep the line between "ordinary developers shouldn't be working with AES" and "ordinary developers can write login systems" clear, you're doing people a disservice, because the two assertions are not alike in how fundamentally true they are.
    - pclmulqdq 2y ago
      By the way, I agree with you. My original point was that the "hivemind" somehow has shifted away from the reasonable conclusion.
      - tptacek 2y ago
        There's nothing personal about any of this, but I'm watching the both the insane poles of this argument ("I'll be just fine inventing my own block cipher modes" guy, "Only a certified security engineer can write a permissions check" guy") go at each other, and wondering why we need to pay any attention to either of them. I haven't so much seen the latter kind of guy, the one saying you need a certified professional to safely output-filter HTML or whatever, but I see "lol block cipher modes whatever" people on HN all the time, on almost every thread about cryptography, dunking on anyone who says "don't roll your own cryptography".
        pclmulqdq 2y ago
        FWIW I see a lot more of the "lol I rolled my own block cipher" crowd in articles here, but a lot more of the "only experts should verify a signature" crowd in the professional world (mostly startup-biased recently). I sort of assume that the latter is a random sampling of software engineers but the former is sampled specifically for idiots who YOLO their crypto.
        tptacek 2y ago
        Only experts should verify signatures! That's actually hard. If you're using minisign or Sigstore or whatever to do something like verify upstream dependencies, sure. But if you're building a system that is about some novel problem domain involving signatures: you should get an expert to verify your system. The trail of dead bodies here is long and bloody.
        pclmulqdq 2y ago
        Yeah, coming up with your own signature scheme to verify authenticity with certain properties is very difficult but also very different in kind from running a pre-designed scheme using a library baked by someone else. I think you have a pre-defined notion when I say the word "signature" about what I meant (perhaps something about software signing or SSL certificates). I literally meant "checking that HMAC-SHA-2 of some bytes is what you expect" (using a library for the hash). Incidentally, that's how you authenticate a JWT.
- stouset 2y ago
  It's complicated, no? Reasonable developers are qualified to do those things. But to build a full-featured authentication subsystem for their webapp? If it's something that holds any kind of reasonably private info, I'm not so sure. Sure, a reasonable developer will use some sort of PBKDF to hash passwords. But when users need a password reset over email, will they know not to store unhashed reset tokens directly in the database? Will they know to invalidate existing sessions when the user's password is reset? Will they reset a browser-stored session ID at login, preventing fixation? And on and on and on. The answer to some of these questions will be yes, but most developers will have a few for which the answer is no. Hell, I've probably built more auth systems than most (and have reported/fixed a few vulnerabilities on well-known open-source auth systems to boot) and I'm honestly not sure I'd trust myself to do it 100% correctly for a system that really mattered. Even outside of "holding the crypto wrong", these things have sharp edges and the more you offload to an existing, well-vetted library the more likely you are to succeed.
  - pas 2y ago
    There are different levels of security. The problem with confidently incorrect level is that it's worse than nothing. Having plaintext tokens (or even passwords) in a DB has its risks, but those risks are (a lot more) obvious, they are not shadowy bugs lying in wait under heaps of code.
    - deleted 2y ago
      [deleted]
  - whatevaa 2y ago
    Based on breaches in systems like Okta and others, I don't think anyone knows how to do it 100% correctly.
    - maqp 2y ago
      Or the companies have figured out it's more expensive to hire a full time professional cryptographer to vet the process, than to deal with the PR for now more or less normalized data breaches.
- ozim 2y ago
  Unfortunately not really. Amount of foot guns in auth flow is high. Implementation of login / password form is just a small piece. Making sure there are no account enumeration possibilities is hard. Making sure 2FA flow is correct and cannot be bypassed is hard. Making proper account recovery flow has its own foot guns. If you can use off the shelf solution where someone already knows about all those - it still stands don’t roll your own.
- tialaramex 2y ago
  There's even bogus "But it's encrypted" crypto in the new software I'm working with in my day job this year 2025. There are so many other "must fix" user visible problems that I actually forgot to mention "Also the cryptography is nonsense, either fix it or remove it" on the one hour review meeting last week, but I should add that. I've made one of these goofs myself when I was much younger (32 byte tokens, attacker can snap them into two 16-byte values, replace either half from another token and that "works" meaning the attacker can take "Becky is an Admin" and "Jimmy is a Customer" glue "y is an Admin" to "Jimm" and make "Jimmy is an Admin") which got caught by someone more experienced before it shipped to end users, but yeah, don't do that.
smolder 2y ago
The stuggle was real in the early web with getting companies to do proper password storage and authentication but the fact that seasoned professionals turn to auth0 or okta (and have been bitten by this reliance!) nowadays strikes me as a little embarrassing.
- switch007 2y ago
  Let's be fair though: Auth0 does a little more than just password authentication Registration, 2FA, reset, email verification, federation, password rules, brute force protection, RBAC/ABAC etc (I'm no fan of Auth0 fwiw)
brianstrimp 2y ago
And the consequence is that people get banged on the head if they either use sth existing (cause they will be using it wrong) or they build sth on their own (because that's obviously bad) or they get fed up and don't use anything. The issue with security researchers, as much as I admire them, is that their main focus is on breaking things and then berating people for having done it wrong. Great, but what should they have done instead? Decided which of the 10 existing solutions is the correct one, with 9 being obvious crap if you ask any security researcher? How should the user know? And typically none of the existing solutions matched the use case exactly. Now what? It's so easy to criticize people left and right. Often justifiably so. But people need to get their shit done and then move on. Isn't that understandable as well?
- soatok 2y ago
  > The issue with security researchers, as much as I admire them, is that their main focus is on breaking things and then berating people for having done it wrong. This is plain incorrect in my experience. Recommended reading (addresses the motivations and ethics of security research): https://soatok.blog/2025/01/21/too-many-people-dont-value-the-time-of-security-researchers/ https://soatok.blog/2025/01/21/too-many-people-dont-value-th... > Great, but what should they have done instead? Decided which of the 10 existing solutions is the correct one, with 9 being obvious crap if you ask any security researcher? There's 10 existing solutions? What is your exact problem space, then? I've literally blogged about tool recommendations before: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I'm also working in all of my spare time on designing a solution to one of the hard problems with cryptographic tooling, as I alluded to in the blog post. https://soatok.blog/2024/06/06/towards-federated-key-transparency/ https://soatok.blog/2024/06/06/towards-federated-key-transpa... Is this not enough of an answer for you? > How should the user know? And typically none of the existing solutions matched the use case exactly. Now what? First, describe your use case in as much detail as possible. The closer you can get to the platonic ideal of a system architecture doc with a formal threat model, the better, but even a list of user stories helps. Then, talk to a cryptography expert. We don't keep the list of experts close to our chest: Any IACR-affiliated conference hosts several of them. We talk to each other! If we're not familiar with your specific technology, there's bound to be someone who is. This isn't presently a problem you can just ask a search engine or generative AI model and get the correct and secure answer for your exact use case 100% of the time with no human involvement. Finding a trusted expert in this field is pretty easy, and most cryptography experts are humble enough to admit when something is out of their depth. And if you're out of better options, this sort of high-level guidance is something I do offer in a timeboxed setting (up to one hour) for a flat rate: https://soatok.com/critiques https://soatok.com/critiques
harrall 2y ago
I feel like there is a huge subset of people who just do trial and error programming. The other day, I watched a whole team of 8 people spend a whole work day swapping out random components on Zoom to diagnose a problem because not a single person considered attaching a debugger to see the exact error in 5 minutes. I feel like you have to tell people to not roll your own whatever because there are so many of these types of people.
- skydhash 2y ago
  I was so surprised the first time I saw this. I mostly work alone and my workflow is usually study an example (docs or project), collect information (books and article), and iteratively build a prototype while learning the domain. Then I saw a colleague literally copying and pasting stuff, hoping that the errors go away in his project. After he asked for my help, I tell him to describe how he planned to solve the problem and he couldn't. For him, it was just endless tweaking until he got something working. And he could have understood the (smallish) problem space by watching one or two videos on YouTube.
- sgarland 2y ago
  Those same people are utterly incapable of reading logs. I’ve had devs send me error messages that say precisely what the problem is, and yet they’re asking me what to do. The form of this that bothers me the most is in infra (the space I work in). K8s is challenging when things go sideways, because it’s a lot of abstractions. It’s far more difficult when you don’t understand how the components underpinning it work, or even basic Linux administration. So there are now a ton of bullshit AI products that are just shipping return codes and error logs out to OpenAI, and sending it back rephrased, with emoji. I know this is gatekeeping, and I do not care: if you can’t run a K8s cluster without an AI tool, you are not qualified to run a K8s cluster. I’m not saying don’t try it; quite the opposite: try it on your own, without AI help, and learn by reading docs and making mistakes (ideally not in prod).

tptacek 2y ago

No it hasn't. The subtext of "don't roll your own crypto" is that "AES" doesn't do, by itself, what most developers think it does; there's a whole literature of how to make AES do anything but transform 16 unstructured bytes into 16 different bytes indistinguishable from random noise; anything past that, including getting AES to encrypt a string, is literally outside of AES's scope. The shorter way of saying this is that you should not use libraries that expose "AES", but instead things like Sodium that expose "boxes" --- and, if you need to do things that Sodium doesn't directly expose, you need an expert. Contra what other people on this thread have suggested, reasonable security engineers do not in fact believe that ordinary developers aren't qualified to build their own password forms or permissions systems; that's a straw man argument.

pclmulqdq 2y ago
Reasonable security engineers take a reasonable position on this. Many other developers (usually uninformed ones) believe this now means "don't make an auth system." Like it or not, this has become a sort of adage that people cargo-cult.
- tptacek 2y ago
  If you can't keep the line between "ordinary developers shouldn't be working with AES" and "ordinary developers can write login systems" clear, you're doing people a disservice, because the two assertions are not alike in how fundamentally true they are.
  - pclmulqdq 2y ago
    By the way, I agree with you. My original point was that the "hivemind" somehow has shifted away from the reasonable conclusion.
    - tptacek 2y ago
      There's nothing personal about any of this, but I'm watching the both the insane poles of this argument ("I'll be just fine inventing my own block cipher modes" guy, "Only a certified security engineer can write a permissions check" guy") go at each other, and wondering why we need to pay any attention to either of them. I haven't so much seen the latter kind of guy, the one saying you need a certified professional to safely output-filter HTML or whatever, but I see "lol block cipher modes whatever" people on HN all the time, on almost every thread about cryptography, dunking on anyone who says "don't roll your own cryptography".
      - pclmulqdq 2y ago
        FWIW I see a lot more of the "lol I rolled my own block cipher" crowd in articles here, but a lot more of the "only experts should verify a signature" crowd in the professional world (mostly startup-biased recently). I sort of assume that the latter is a random sampling of software engineers but the former is sampled specifically for idiots who YOLO their crypto.
        tptacek 2y ago
        Only experts should verify signatures! That's actually hard. If you're using minisign or Sigstore or whatever to do something like verify upstream dependencies, sure. But if you're building a system that is about some novel problem domain involving signatures: you should get an expert to verify your system. The trail of dead bodies here is long and bloody.
        pclmulqdq 2y ago
        Yeah, coming up with your own signature scheme to verify authenticity with certain properties is very difficult but also very different in kind from running a pre-designed scheme using a library baked by someone else. I think you have a pre-defined notion when I say the word "signature" about what I meant (perhaps something about software signing or SSL certificates). I literally meant "checking that HMAC-SHA-2 of some bytes is what you expect" (using a library for the hash). Incidentally, that's how you authenticate a JWT.
stouset 2y ago
It's complicated, no? Reasonable developers are qualified to do those things. But to build a full-featured authentication subsystem for their webapp? If it's something that holds any kind of reasonably private info, I'm not so sure. Sure, a reasonable developer will use some sort of PBKDF to hash passwords. But when users need a password reset over email, will they know not to store unhashed reset tokens directly in the database? Will they know to invalidate existing sessions when the user's password is reset? Will they reset a browser-stored session ID at login, preventing fixation? And on and on and on. The answer to some of these questions will be yes, but most developers will have a few for which the answer is no. Hell, I've probably built more auth systems than most (and have reported/fixed a few vulnerabilities on well-known open-source auth systems to boot) and I'm honestly not sure I'd trust myself to do it 100% correctly for a system that really mattered. Even outside of "holding the crypto wrong", these things have sharp edges and the more you offload to an existing, well-vetted library the more likely you are to succeed.
- pas 2y ago
  There are different levels of security. The problem with confidently incorrect level is that it's worse than nothing. Having plaintext tokens (or even passwords) in a DB has its risks, but those risks are (a lot more) obvious, they are not shadowy bugs lying in wait under heaps of code.
  - deleted 2y ago
    [deleted]
- whatevaa 2y ago
  Based on breaches in systems like Okta and others, I don't think anyone knows how to do it 100% correctly.
  - maqp 2y ago
    Or the companies have figured out it's more expensive to hire a full time professional cryptographer to vet the process, than to deal with the PR for now more or less normalized data breaches.
ozim 2y ago
Unfortunately not really. Amount of foot guns in auth flow is high. Implementation of login / password form is just a small piece. Making sure there are no account enumeration possibilities is hard. Making sure 2FA flow is correct and cannot be bypassed is hard. Making proper account recovery flow has its own foot guns. If you can use off the shelf solution where someone already knows about all those - it still stands don’t roll your own.
tialaramex 2y ago
There's even bogus "But it's encrypted" crypto in the new software I'm working with in my day job this year 2025. There are so many other "must fix" user visible problems that I actually forgot to mention "Also the cryptography is nonsense, either fix it or remove it" on the one hour review meeting last week, but I should add that. I've made one of these goofs myself when I was much younger (32 byte tokens, attacker can snap them into two 16-byte values, replace either half from another token and that "works" meaning the attacker can take "Becky is an Admin" and "Jimmy is a Customer" glue "y is an Admin" to "Jimm" and make "Jimmy is an Admin") which got caught by someone more experienced before it shipped to end users, but yeah, don't do that.

smolder 2y ago

The stuggle was real in the early web with getting companies to do proper password storage and authentication but the fact that seasoned professionals turn to auth0 or okta (and have been bitten by this reliance!) nowadays strikes me as a little embarrassing.

switch007 2y ago
Let's be fair though: Auth0 does a little more than just password authentication Registration, 2FA, reset, email verification, federation, password rules, brute force protection, RBAC/ABAC etc (I'm no fan of Auth0 fwiw)

brianstrimp 2y ago

And the consequence is that people get banged on the head if they either use sth existing (cause they will be using it wrong) or they build sth on their own (because that's obviously bad) or they get fed up and don't use anything. The issue with security researchers, as much as I admire them, is that their main focus is on breaking things and then berating people for having done it wrong. Great, but what should they have done instead? Decided which of the 10 existing solutions is the correct one, with 9 being obvious crap if you ask any security researcher? How should the user know? And typically none of the existing solutions matched the use case exactly. Now what? It's so easy to criticize people left and right. Often justifiably so. But people need to get their shit done and then move on. Isn't that understandable as well?

soatok 2y ago
> The issue with security researchers, as much as I admire them, is that their main focus is on breaking things and then berating people for having done it wrong. This is plain incorrect in my experience. Recommended reading (addresses the motivations and ethics of security research): https://soatok.blog/2025/01/21/too-many-people-dont-value-the-time-of-security-researchers/ https://soatok.blog/2025/01/21/too-many-people-dont-value-th... > Great, but what should they have done instead? Decided which of the 10 existing solutions is the correct one, with 9 being obvious crap if you ask any security researcher? There's 10 existing solutions? What is your exact problem space, then? I've literally blogged about tool recommendations before: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I'm also working in all of my spare time on designing a solution to one of the hard problems with cryptographic tooling, as I alluded to in the blog post. https://soatok.blog/2024/06/06/towards-federated-key-transparency/ https://soatok.blog/2024/06/06/towards-federated-key-transpa... Is this not enough of an answer for you? > How should the user know? And typically none of the existing solutions matched the use case exactly. Now what? First, describe your use case in as much detail as possible. The closer you can get to the platonic ideal of a system architecture doc with a formal threat model, the better, but even a list of user stories helps. Then, talk to a cryptography expert. We don't keep the list of experts close to our chest: Any IACR-affiliated conference hosts several of them. We talk to each other! If we're not familiar with your specific technology, there's bound to be someone who is. This isn't presently a problem you can just ask a search engine or generative AI model and get the correct and secure answer for your exact use case 100% of the time with no human involvement. Finding a trusted expert in this field is pretty easy, and most cryptography experts are humble enough to admit when something is out of their depth. And if you're out of better options, this sort of high-level guidance is something I do offer in a timeboxed setting (up to one hour) for a flat rate: https://soatok.com/critiques https://soatok.com/critiques

harrall 2y ago

I feel like there is a huge subset of people who just do trial and error programming. The other day, I watched a whole team of 8 people spend a whole work day swapping out random components on Zoom to diagnose a problem because not a single person considered attaching a debugger to see the exact error in 5 minutes. I feel like you have to tell people to not roll your own whatever because there are so many of these types of people.

skydhash 2y ago
I was so surprised the first time I saw this. I mostly work alone and my workflow is usually study an example (docs or project), collect information (books and article), and iteratively build a prototype while learning the domain. Then I saw a colleague literally copying and pasting stuff, hoping that the errors go away in his project. After he asked for my help, I tell him to describe how he planned to solve the problem and he couldn't. For him, it was just endless tweaking until he got something working. And he could have understood the (smallish) problem space by watching one or two videos on YouTube.
sgarland 2y ago
Those same people are utterly incapable of reading logs. I’ve had devs send me error messages that say precisely what the problem is, and yet they’re asking me what to do. The form of this that bothers me the most is in infra (the space I work in). K8s is challenging when things go sideways, because it’s a lot of abstractions. It’s far more difficult when you don’t understand how the components underpinning it work, or even basic Linux administration. So there are now a ton of bullshit AI products that are just shipping return codes and error logs out to OpenAI, and sending it back rephrased, with emoji. I know this is gatekeeping, and I do not care: if you can’t run a K8s cluster without an AI tool, you are not qualified to run a K8s cluster. I’m not saying don’t try it; quite the opposite: try it on your own, without AI help, and learn by reading docs and making mistakes (ideally not in prod).