Live data from Hacker News

Bypassing Browser Security Warnings with Pseudo Password Fields

troyhunt.com

71–80 of 127 posts

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#71

This hack is exactly what I needed 2 days ago while working on a browser-based terminal app. My site will be secured with SSL/TLS, but I needed a way to make a content-editable span mask input like a password field. I already implemented it with a password input, but it doesn't wrap inline like a span does. It will be much cleaner to just add a class that masks the font.

Most terminal apps I use when you type in a password area nothing shows at all in the terminal (not even a mask). Though admittedly, that is not the best user experience for providing feedback.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#72
Edit: Ignore this. It seems most of the posts I was talking about were either deleted or edited. Keeping my original message here for completeness sake.

---

The number of people saying that this is a clever workaround and agreeing with the people putting in the bug reports is very disheartening to see on HN. If a highly technical crowd such as HN can't get why HTTPS is important than what hope does everyone else have?

Troy hunt is a security researcher. The examples of the bug reports and quotes were meant to terrify and it worked on me. If I was a customer of any of these examples I would be pissed. If you're not upset and/or frightened please for everyone's sake take an infosec course or read up on the subject.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#73

If only we had these kinds of strong warnings in the VOIP industry. Nearly every provider barebacks the internet, throwing unencrypted signaling data (phone number dialed, keys pressed during the call, codec to use) and call media over the internet raw, just hoping that no one eavesdrops or alters their data. HIPPA compliance? Nah bruh, unencrypted UDP is just fine! PCI-DSS says we can't take credit cards over this w…

I've seen PBX people find religion once they wake up Monday morning to a weekend of hacked calls to Africa. Though sometimes that religion is in the form of yelling at upstream providers to please give them refunds.

And because of these insecure systems, the more serious issues (all this SIP software is tons of C, and I've found exploits in just 1000 line utilities, let alone protocol level hackery and other fun) get ignored. I found a simple redirect bug in a VoIP platform. Ignored. Later some guy used it to the tune of $90K.

I don't want to become a criminal outright but I've gone from a "friendly disclosure offline and let you lie about fixing issues" to "Sit on 'em and sell 'em one day" model because everyone's so obtuse.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#74

If only we had these kinds of strong warnings in the VOIP industry. Nearly every provider barebacks the internet, throwing unencrypted signaling data (phone number dialed, keys pressed during the call, codec to use) and call media over the internet raw, just hoping that no one eavesdrops or alters their data. HIPPA compliance? Nah bruh, unencrypted UDP is just fine! PCI-DSS says we can't take credit cards over this w…

I've seen PBX people find religion once they wake up Monday morning to a weekend of hacked calls to Africa. Though sometimes that religion is in the form of yelling at upstream providers to please give them refunds. And because of these insecure systems, the more serious issues (all this SIP software is tons of C, and I've found exploits in just 1000 line utilities, let alone protocol level hackery and other fun) get…

SIP... doesn't seem like the greatest protocol. Maybe I'm tainted because I've only really dealt with it in the context of the Microsoft IM/telephony platforms (renamed constantly, but always essentially the same), but it appears to be incredibly brittle complicated. On anything less than a local LAN, messages get dropped or mangled or timed out all the time, and that trashes connections, or puts sessions into unrecoverable states.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#75
post #70

Earlier quoted context omitted.

My claim is about the debate itself, not about any certain vaccine or danger.

So far you're following the anti-vax script perfectly: lots of FUD, no claims specified in enough detail to even evaluate them much less counteract the overwhelming evidence that vaccines are a public good with no reputable downside.

I've been supplying information and you've been complaining. I fail to see how I'm at fault for trying to answer questions.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#76

"I’ve been speaking with the owner about SSL before I invest in becoming a member, but she’s been told by the dev of the platform (it’s a franchise system called ShopCity.com) that SSL is more about Google’s monopolizing visibility of content, and less to do with security" This is an interesting observation of how Google's technical crusades often align with its profit interests. The main threat that HTTPS everywhere…

> The main threat that HTTPS everywhere secures against is preventing your ISP from analyzing your traffic in order to build and sell an advertising profile on you. That is not true. The main threat it protects against is MitM (man in the middle attacks) that allow someone to redirect all traffic to a website through their machine and thus see all the data including your password. HTTPS when combined with root certif…

Or MitM and swap out G ads for someone else’s ads?

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#77
post #19

Earlier quoted context omitted.

I believe it's either (a) a lack of understanding of _why_ one should use SSL or (b) a mistaken sense of principle of standing up to the perceived bulliness of Google, which, come to think of it, it's basically an application of (a)

> (b) a mistaken sense of principle of standing up to the perceived bulliness of Google, which, come to think of it, it's basically an application of (a) But Google has been bullying around with their behaviour. I don't think that's even debatable.

They have been bullying around, but their enforcement of HTTPS for forms with password inputs shouldn't count as one of their instances of bullying. It's something browser vendors should have implemented long ago, even before LetsEncrypt came along, because it is highly insecure and users should know about it.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#79

Edit: Ignore this. It seems most of the posts I was talking about were either deleted or edited. Keeping my original message here for completeness sake. --- The number of people saying that this is a clever workaround and agreeing with the people putting in the bug reports is very disheartening to see on HN. If a highly technical crowd such as HN can't get why HTTPS is important than what hope does everyone else have…

> The number of people saying that this is a clever workaround and agreeing with the people putting in the bug reports is very disheartening to see on HN

Huh? I've been through this entire thread and I haven't seen anyone suggest that this is acceptable behavior; even in the heavily-downvoted comments. It's mostly just people laughing at the lengths this site went to to shoot itself in the foot.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#80

This hack is exactly what I needed 2 days ago while working on a browser-based terminal app. My site will be secured with SSL/TLS, but I needed a way to make a content-editable span mask input like a password field. I already implemented it with a password input, but it doesn't wrap inline like a span does. It will be much cleaner to just add a class that masks the font.

Most terminal apps I use when you type in a password area nothing shows at all in the terminal (not even a mask). Though admittedly, that is not the best user experience for providing feedback.

I wonder if terminal apps hook into the same security input APIs from the OS that browsers are using for password inputs.
Post reply on HN