Hacker News Reader

Comment by codedokode | Hacker News Reader

> What’s going on in that user object? The pin field seems suspiciously related to the PIN we were asked to input after creating our account

This might be the fault of opt-out serialization library (by default it serializes the whole object and you need to manually opt-out fields from it). So a programmer adds a field, forgets to add opt-out annotation and voilà.

Or they are just using plain JS dicts on the server and forgot to remove the key before using it in a response.

> The vulnerability they’re talking about was presented in a paper by researchers at the University of Vienna.

This vulnerability (mapping phone numbers to user id via rendevouz API) is old and was exploited in 2016 in Telegram [1] and allowed Iranian govt to build a phone book of 15M Telegram users. The paper also mentions that the vulnerability was known in 2012, still not fixed.

[1] https://telegram.org/blog/15million-reuters

View on HN

> This might be the fault of opt-out serialization library (by default it serializes the hole object and you need to manually opt-out fields from it). So a programmer adds a field, forgets to add opt-out annotation and voilà.

In a previous job, on my first audit of the code, I spotted such vulnerabilities pretty much everywhere.

Developers simply need to stop using these libraries.

This is such a common issue I've seen in so many API backends, where sensitive fields on a record are getting sent to the client and no one notices because it's invisible in the UI.

The fact that the PIN is leaked is bad enough, but it also happens to be plaintext. This is a password. It should not be stored unhashed, and it should be hashed with strong algorithms.

It’s a 6 digit pin. Doesn’t seem worthwhile to hash. What are the best practices here? I’m not sure

There is never a need to store a pin in the database, store it in temporary storage like redis. Set the TTL to the expiration date. You can hash if needed, but I’m less concerned that someone hacks into your reds instance and steals your pins from the last 10 minutes, bc everything else is gone.

There should never be a need to return a pin to the client. You’ve already texted/emailed it to them. They are going to send it back to you. You will check against your temporary storage, verify/reject, and delete it immediately after.

Yeah, you can only delay attacks by a tiny little bit, but the search space of 10^6 is just too small. Salting it doesn't give you much more security.

Sure. But why are we blaming libraries. This is the development process. Are BE developers not looking at their output anymore? Are we just vibe coding everything? If the UI does not complain then go to prod? This can’t be the expectation. And then you claim that your app is secure. Based on what review. Does not look like you even did an internal review? If you’re going to design a PIN feature, and don’t consider securing it, what part of design did you do?

I keep seeing people try to explain away incompetence by blaming unaccountable things aka the tool or system. Exposed password? Must be the library. People really should stop using it. No, the library is not wrong, ppl should be better developers.

Peer reviewed paper is full of AI slop, must not be the reviewer’s fault, the citations were there, they were just fake. What is going on?

Reply on news.ycombinator.com