HN user

Ronnie76er

62 karma

[ my public key: https://keybase.io/ronnie76er; my proof: https://keybase.io/ronnie76er/sigs/T_PMnZ-EC4aERmP15Lm5PqthjbNI4FhbEtsz5nBPkR4 ]

Posts3
Comments11
View on HN

As others have noted, this feels like an issue in the relying parties not relying on the `sub` field to validate the user. It feels the exact same as this issue here: https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a....

In both, the details around the `sub` field, the field that should actually be used to identify the user, is poorly described. I would say that both of these feel a bit sensationalist, but then again, if relying parties are NOT using the sub field to validate users, they should be called out.

It seems to be that a good way to make some money is find every such situation where RPs are not using sub, and submit vuln bugs.

My Pixel 8 (not sure what other Android phones do this) can screen calls using their AI assistant. It asks what the call is about. If they answer, it displays the text to you as it rings through.

It sounds surprisingly human-like, even saying "Hello?" in a slightly annoyed tone when the other person doesn't respond in time.

Check out the RSA spec here: https://datatracker.ietf.org/doc/html/rfc8017#section-8.2.2. It's still verification, because all you need is a message and a signature. The message can be constructed from the data in the diploma, presumably. It's just, it's not disclosed to you how to construct the message (maybe it is online somewhere). So a verifier could construct the same message you decrypted, and then run the verification function.

In my dim recollection, I've used mail clients that used OAuth for IMAP access, plus it appears they are not taking away App Passwords, which I use for almost all my mail clients.

Just want to mention something about the id_token provided. I'm on my phone, so I don't have apples implementation handy, but in OIDC, the relying party (Spotify for example) is supposed to use the id_token to verify the user that is authenticated, specifically the sub claim in the jwt id_token.

https://openid.net/specs/openid-connect-core-1_0-final.html#...

It's likely (although like others have noted, this is scant on details), that this value was correct and represented the authenticated user.

A relying party should not use the email value to authenticate the user.

Not contesting that this is a bug that should be fixed and a potential security issue, but perhaps not as bad.

Anyone else? Am I reading this right?

I think it's also possible you are getting a false positive, because it's timing out or whatever. The newer version of that check tells you if it's timing out.

Newtown Square, PA (Philadelphia suburbs)

konciergeMD (http://konciergemd.com/) is an early stage startup in the Philly suburbs. We're building a product that changes how caregivers and providers collaborate to deliver healthcare. We're a small, polyglot team with diverse backgrounds. Our stack is Java/Scala on the back end and HTML5/CSS3/Javascript on the front end. We care deeply about aesthetics. We care deeply about coffee. We are seeking developers who are equally comfortable with front and back end development and who understand web-scale, high-availability, high-traffic application architectures.

We're looking to bring on a top-notch software engineer, a pragmatist focused on shipping. We are open to contract or full-time work candidates. You will play a role in shaping this product -- this is core to our culture, so bring your opinions. We're generalists, but the path we're blazing will heavily rely on Javascript, jQuery, Backbone.js, HTML5, CSS3, Java, Scala, Play Framework, and Amazon Web Services. We're web first but mobile is quickly approaching on the horizon. Bonus points if you have experience working with medical informatics. Gold stars if you have experience working with big data, machine learning, or semantic web.

If you're interested, ping ron@konciergemd.com.

Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.