We didn't encrypt your password, we hashed it

Re:We didn't encrypt your password, we hashed it by Mountain_Skies on Friday September 04, 2020 @10:09PM (#24380846)

One of the hats I wear these days is looking through source code for security vulnerabilities. It's shocking how many SQL injection vulnerabilities I find in newly written code. I remember first reading about SQL injection back in the 90s and yet developers are still making that very basic mistake. It is also a bit scary how many of the code analysist tools miss intentional flaws I've added to the code to test the scanner. These aren't ancient lint checkers, they're ridiculously priced enterprise tools. It worries me that they're giving a false sense of security that is going to get lots of implementations burned.

[ Parent | on HN ]

Re:We didn't encrypt your password, we hashed it by mgkimsal on Friday September 04, 2020 @10:35PM (#24380964)

>These aren't ancient lint checkers, they're ridiculously priced enterprise tools. It worries me that they're giving a false sense of security that is going to get lots of implementations burned.

But no one is going to get fired or held back for choosing those 'enterprise' tools. They've spent a lot of money, everyone has a checklist, and people move on, even if there's a breach. And some jr might have pointed out "hey, this open source toolset does this, but is kept up to date and has found 47 things our scanner didn't find" and this jr will likely be ignored.

[ Parent | on HN ]

Re:We didn't encrypt your password, we hashed it by sokoloff on Saturday September 05, 2020 @08:09AM (#24382997)

“Well with open source tools, you pay with time and we prefer this gold-plated, Cadillac, enterprise-grade tool. We’re a serious company now, after all.”

It’s maddening.

[ Parent | on HN ]

Re:We didn't encrypt your password, we hashed it by greggman3 on Saturday September 05, 2020 @02:06AM (#24381687)

I'd argue it's bad API design. You can't make an API that's easy to use wrong and insecurely and then be surprised that people use it wrong and insecurely.

[ Parent | on HN ]

Re:We didn't encrypt your password, we hashed it by 0xFluegel on Saturday September 05, 2020 @06:30AM (#24382648)

I can only half agree with you on that. Yes, I also dislike APIs that make wrong or unsafe use easy and correct use more bothersome but seemingly no different in behaviour (until it goes BOOM), but I also find that soooo many people simply don't have the awareness that they are interfacing with another system that interprets their data in a potentially unsafe way. And these people will misuse any API like this.

[ Parent | on HN ]

Re:We didn't encrypt your password, we hashed it by larssorenson on Saturday September 05, 2020 @11:27AM (#24384262)

Unfortunately short of forcing everyone to use an ORM I don't see how we can block the unsafe API, which I'm assuming to be the string-based query interface e.g. `conn.query("SELECT * FROM users")` since any interface that accepts a string will allow a dynamically constructed string which lets developers open themselves to injection attacks. Only ORMs AFAIK can prevent this, e.g. db().users.all() or db().users.select(name="bob").

Maybe there's a clever trick I'm missing here.

[ Parent | on HN ]

Re:We didn't encrypt your password, we hashed it by aaronmdjones on Saturday September 05, 2020 @07:37PM (#24387712)

It'd be nice if the languages offered a way for the query-compiling function to require that the query strings given to it are static, compile-time strings.

[ Parent | on HN ]