14 ms·

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

by foota 10y ago

bsimpson 10y ago
Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Looks like they have a service called Flexible SSL that terminates HTTPS at the CDN, and sends unencrypted traffic to your backend: https://www.cloudflare.com/ssl/ https://www.cloudflare.com/ssl/
- UnoriginalGuy 10y ago
  That's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable. Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.
  - JoshTriplett 10y ago
    My previous router did this to obscure password length, by inserting three stars into the field for every character typed. Which completely broke browser password managers, and the ability to paste the password.
    - deleted 10y ago
      [deleted]
  - duskwuff 10y ago
    IIRC, changing the 'type' of an input doesn't (or, at least, didn't) work in some browsers.
- guscost 10y ago
  > an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways. For anyone who is wondering what these ways are, here are a couple: 1) Backspace is a crufty special case 2) What happens when someone highlights text in the input box and types over it?
  - skybrian 10y ago
    CodeMirror has figured this out. When you type it's actually into a hidden input, and it updates a separate display. Reimplementing CodeMirror (including highlighting, etc) is hard enough that most web developers probably can't do it. But it only takes one person to create a library.
  - dTal 10y ago
    More broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days. So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about? You certainly can't get away with just wiring keystrokes to a field.
    - eru 10y ago
      You can: you'll just get a buggy half-assed implementation. In a corporate envirnonment with bad politics, that might still be the only way to go. (Apart from quitting.)
- paulddraper 10y ago
  > onKeyDown Right-click paste from my password manager, and it doesn't work. Thanks. --- This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.
  - brak1 10y ago
    also type='password' don't get their submitted values suggested for the autocomplete thing in broswers.
    - Klathmon 10y ago
      You can avoid this by using `autocomplete='off'`. Most browsers will still allow you to autocomplete the field because many were abusing that attribute, but they won't save what you put in it. It's still a horrible idea, but it'd work.
- dheera 10y ago
  A few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate with it over post messages.
  - Moru 10y ago
    But what do you do when you have a page with form data that isn't sensitive and has no password on it and the users can't care less about the content of the form but chrome still warns about unsecure page?
    - kevin_thibedeau 10y ago
      Why would such a form need a password field?
      - Moru 10y ago
        Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections... There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.
        Piskvorrr 10y ago
        Well...HTTP is insecure. That's what S in HTTPS stands for.
        comex 10y ago
        I haven't heard of this bug, but regarding the decision to mark all HTTP as insecure: Remember, HTTPS isn't just for security, but also privacy. And even if your site is such that there is no privacy advantage in hiding the exact URL you visited (as opposed to the hostname, which unfortunately must leak for now), even if there are no cookies sent to your site, or to any iframes it uses, which can be used for identification or profiling… Even then, there are the benefits that only accrue if a user's entire browsing session is HTTP-free, including hiding the user agent from a network attacker and preventing injection of everything from tracking cookies to DDOS scripts (China's Great Cannon) to zero-day attacks.
- PretzelFisch 10y ago
  you can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low<sarcasm/>...
  - dawnerd 10y ago
    I've noticed a lot of sites default to "show password" with a toggle so it wouldn't be insane to think they'd opt for plaintext the whole way.
- barnacs 10y ago
  > I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Interesting. Where are all these warnings when a CDN man in the middle attacks your connection? Or when google gets to access all the email communication of gmail users? Or when ad networks track you all around the web?
- djs070 10y ago
  IIRC, type=password also prevents copying saved input to clipboard
- nodesocket 10y ago
  +1 for using CloudFlare. I just deployed the front-end website for my new startup (https://elasticbyte.net https://elasticbyte.net) using Google Cloud Storage (like S3) and CloudFlare for custom SSL. CloudFlare also allows me utilize CNAME flattening, so the the root record for my domain simply points to c.storage.googleapis.com.
1qaz2wsx3edc 10y ago
Developer - "any could see the password..." Pm - "put one of them modal over it" Developer - "but then how will anyone..." Pm - "we're switching to <completely different stack they heard about from someone in their uber last week>"
AtheistOfFail 10y ago
Yay, plaintext input fields for passwords. /me opens a sake bottle.
brettz 10y ago
So accurate. We had this exact discussion. Going to go with insecure warnings until we get https up shortly. For those wondering you can mask a normal text field in css input { -webkit-text-security: disc; }.
- mappu 10y ago
  My colleague used a custom web font where every glyph was replaced with a filled circle. Better browser compatibility, you know. Although our reason was actually to do with password managers. At $DAYJOB we have a CRM/ERP system with lots of password fields for other entities (not the current cookie user). It's increasingly difficult to opt out of browser autofill, and LastPass in particular was corrupting password data in the system whenever forms were submitted.
  - fdsaaf 10y ago
    > It's increasingly difficult to opt out of browser autofill Good. I hope browsers autodetect these web font tricks and pop up similar warnings. I can't stand when some random website make thinks it can do a better job of credential security than major browser makers.
    - Symbiote 10y ago
      I think the point is more like an HR administrator who opens a web page, containing an employee's details. They need to update the employee's home phone number, but their password manager dumps the HR administrator's password into the "Set new password" field, which is therefore overwritten.
      - icebraining 10y ago
        So don't put the "set new password" field right in the employee's details page, use an extra page or popup for that.
        mappu 10y ago
ranveeraggarwal 10y ago
Pm - "why can't you use some JavaScript to hide this?" Developer - "..."
- dawnerd 10y ago
  The correct answer is always "IE doesn't support it"
  - ranveeraggarwal 10y ago
    Good point. We use the Windows stack :D
bradgessler 10y ago
It would be better if form is served up via HTTP it gets marked as insecure.
nolite 10y ago
The Law of Unintended Consequences at its best
JustSomeNobody 10y ago
I laughed out loud. Then started crying. Sigh. Our industry in a nutshell.
Aldo_MX 10y ago
I've seen that: https://www.bancomer.com/index.jsp https://www.bancomer.com/index.jsp Click "Acceso a clientes" and write numbers.
- eru 10y ago
  I don't even get to that badness: the browser needs to accept third-party cookies first. (I wonder what badness is behind all there.)
fdsaaf 10y ago
I'm glad I'm not the only developer who can't stand the kind of PM you describe.
madeofpalk 10y ago
Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't http?"
technion 10y ago
Well I'm fairly certain it will go like this for me. Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "we'll need to setup encryption. It will need to be FIPS-140 certified or it's not secure" Developer - "But you didn't care when there was no encryption" Pm - "We don't need to certify plaintext, that should be obvious. You need to learn more about security".
- morenoh149 10y ago
  where do you work
  - msimpson 10y ago
    They seem to be a government contractor.
- theandrewbailey 10y ago
  Developer - "FIPS-140 has been compromised by the NSA. We don't want government spies in our servers."
drzaiusapelord 10y ago
Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field" Pm - "If its important enough to hide, its important enough to stop from being intercepted. Think social security numbers, PINs, tokens, drivers license numbers, etc. Why aren't we encrypting things that matter?"

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

by foota 10y ago

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"

bsimpson 10y ago

Don't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Looks like they have a service called Flexible SSL that terminates HTTPS at the CDN, and sends unencrypted traffic to your backend: https://www.cloudflare.com/ssl/ https://www.cloudflare.com/ssl/

UnoriginalGuy 10y ago
That's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable. Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.
- JoshTriplett 10y ago
  My previous router did this to obscure password length, by inserting three stars into the field for every character typed. Which completely broke browser password managers, and the ability to paste the password.
  - deleted 10y ago
    [deleted]
- duskwuff 10y ago
  IIRC, changing the 'type' of an input doesn't (or, at least, didn't) work in some browsers.
guscost 10y ago
> an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways. For anyone who is wondering what these ways are, here are a couple: 1) Backspace is a crufty special case 2) What happens when someone highlights text in the input box and types over it?
- skybrian 10y ago
  CodeMirror has figured this out. When you type it's actually into a hidden input, and it updates a separate display. Reimplementing CodeMirror (including highlighting, etc) is hard enough that most web developers probably can't do it. But it only takes one person to create a library.
- dTal 10y ago
  More broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days. So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about? You certainly can't get away with just wiring keystrokes to a field.
  - eru 10y ago
    You can: you'll just get a buggy half-assed implementation. In a corporate envirnonment with bad politics, that might still be the only way to go. (Apart from quitting.)
paulddraper 10y ago
> onKeyDown Right-click paste from my password manager, and it doesn't work. Thanks. --- This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.
- brak1 10y ago
  also type='password' don't get their submitted values suggested for the autocomplete thing in broswers.
  - Klathmon 10y ago
    You can avoid this by using `autocomplete='off'`. Most browsers will still allow you to autocomplete the field because many were abusing that attribute, but they won't save what you put in it. It's still a horrible idea, but it'd work.
dheera 10y ago
A few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate with it over post messages.
- Moru 10y ago
  But what do you do when you have a page with form data that isn't sensitive and has no password on it and the users can't care less about the content of the form but chrome still warns about unsecure page?
  - kevin_thibedeau 10y ago
    Why would such a form need a password field?
    - Moru 10y ago
      Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections... There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.
      - Piskvorrr 10y ago
        Well...HTTP is insecure. That's what S in HTTPS stands for.
      - comex 10y ago
        I haven't heard of this bug, but regarding the decision to mark all HTTP as insecure: Remember, HTTPS isn't just for security, but also privacy. And even if your site is such that there is no privacy advantage in hiding the exact URL you visited (as opposed to the hostname, which unfortunately must leak for now), even if there are no cookies sent to your site, or to any iframes it uses, which can be used for identification or profiling… Even then, there are the benefits that only accrue if a user's entire browsing session is HTTP-free, including hiding the user agent from a network attacker and preventing injection of everything from tracking cookies to DDOS scripts (China's Great Cannon) to zero-day attacks.
PretzelFisch 10y ago
you can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low<sarcasm/>...
- dawnerd 10y ago
  I've noticed a lot of sites default to "show password" with a toggle so it wouldn't be insane to think they'd opt for plaintext the whole way.
barnacs 10y ago
> I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Interesting. Where are all these warnings when a CDN man in the middle attacks your connection? Or when google gets to access all the email communication of gmail users? Or when ad networks track you all around the web?
djs070 10y ago
IIRC, type=password also prevents copying saved input to clipboard
nodesocket 10y ago
+1 for using CloudFlare. I just deployed the front-end website for my new startup (https://elasticbyte.net https://elasticbyte.net) using Google Cloud Storage (like S3) and CloudFlare for custom SSL. CloudFlare also allows me utilize CNAME flattening, so the the root record for my domain simply points to c.storage.googleapis.com.

1qaz2wsx3edc 10y ago

Developer - "any could see the password..." Pm - "put one of them modal over it" Developer - "but then how will anyone..." Pm - "we're switching to <completely different stack they heard about from someone in their uber last week>"

AtheistOfFail 10y ago

Yay, plaintext input fields for passwords. /me opens a sake bottle.

brettz 10y ago

So accurate. We had this exact discussion. Going to go with insecure warnings until we get https up shortly. For those wondering you can mask a normal text field in css input { -webkit-text-security: disc; }.

mappu 10y ago
My colleague used a custom web font where every glyph was replaced with a filled circle. Better browser compatibility, you know. Although our reason was actually to do with password managers. At $DAYJOB we have a CRM/ERP system with lots of password fields for other entities (not the current cookie user). It's increasingly difficult to opt out of browser autofill, and LastPass in particular was corrupting password data in the system whenever forms were submitted.
- fdsaaf 10y ago
  > It's increasingly difficult to opt out of browser autofill Good. I hope browsers autodetect these web font tricks and pop up similar warnings. I can't stand when some random website make thinks it can do a better job of credential security than major browser makers.
  - Symbiote 10y ago
    I think the point is more like an HR administrator who opens a web page, containing an employee's details. They need to update the employee's home phone number, but their password manager dumps the HR administrator's password into the "Set new password" field, which is therefore overwritten.
    - icebraining 10y ago
      So don't put the "set new password" field right in the employee's details page, use an extra page or popup for that.
      - mappu 10y ago

ranveeraggarwal 10y ago

Pm - "why can't you use some JavaScript to hide this?" Developer - "..."

dawnerd 10y ago
The correct answer is always "IE doesn't support it"
- ranveeraggarwal 10y ago
  Good point. We use the Windows stack :D

bradgessler 10y ago

It would be better if form is served up via HTTP it gets marked as insecure.

nolite 10y ago

The Law of Unintended Consequences at its best

JustSomeNobody 10y ago

I laughed out loud. Then started crying. Sigh. Our industry in a nutshell.

Aldo_MX 10y ago

I've seen that: https://www.bancomer.com/index.jsp https://www.bancomer.com/index.jsp Click "Acceso a clientes" and write numbers.

eru 10y ago
I don't even get to that badness: the browser needs to accept third-party cookies first. (I wonder what badness is behind all there.)

fdsaaf 10y ago

I'm glad I'm not the only developer who can't stand the kind of PM you describe.

madeofpalk 10y ago

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't http?"

technion 10y ago

Well I'm fairly certain it will go like this for me. Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "we'll need to setup encryption. It will need to be FIPS-140 certified or it's not secure" Developer - "But you didn't care when there was no encryption" Pm - "We don't need to certify plaintext, that should be obvious. You need to learn more about security".

morenoh149 10y ago
where do you work
- msimpson 10y ago
  They seem to be a government contractor.
theandrewbailey 10y ago
Developer - "FIPS-140 has been compromised by the NSA. We don't want government spies in our servers."

drzaiusapelord 10y ago

Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field" Pm - "If its important enough to hide, its important enough to stop from being intercepted. Think social security numbers, PINs, tokens, drivers license numbers, etc. Why aren't we encrypting things that matter?"