Hacker News Reader

Comment by jdelman | Hacker News Reader

My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York.

I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figured it would be OK. I input my username and password using my password manager but it didn’t work. Pretty strange, as I was able to log in to the “main” EZpass site using those same credentials. I tried logging in on the payment site again to no avail. Finally I realized that my password was being truncated by the password input field itself.

The solution was to inspect the page and change the maxlen attribute of the password field.

View on HN

I've lost count of how many times I had to "fix" broken sites by editing the javascript manually client side.

The maximum length of text in a field could be (and should be if it's actually necessary) an attribute in the HTML. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

What's your process of editing client side JS? Is there some method to capture scripts before they load so you can make your modifications?

You can run a new script that overrides any reachable function. Right from the console.

Say there is a function named ‘verifyPassword()’ you can simply run ‘verifyPassword=function(pass){ return true }’

chrome does have overrides in developer tools - it supports persistent script editation. https://developers.google.com/web/updates/2018/01/devtools#o...

Ah, thanks for the link, that's super neat! I was looking for making changes that would persist across page loads or browser restarts, and this is exactly that. It's a shame that it's not a feature in Firefox's dev tools (not yet anyways)

In chrome, if you open the dev tools and go to Sources, you can see the files and modify them right there. If they are executed once at page load time, you need to set a breakpoint and refresh, edit, save, then press Run again.

Often times when I'm fixing sites, there's an actual error thrown in the console, which will take you to the line in the code where the exception happens (or any line along the stack trace), so you can set a breakpoint right there and fix the code. If the code is minified, there's also a button near the bottom of the code section to reformat it./

The only tricky part is if the JS is embedded inside the html, then Chrome doesn't let you edit it, but often then, it's in the global Window namespace, so you can literally override the function by typing in the console. Hope this helps!

As a hands-on example, you can open hn.js on this page, add `alert('hello')` to vote(){}, save, then try upvoting my comment :)

Mine is my workplace. They mandate changing the password every 3 months (so most people use post-its) and their password change utility accepts special characters for input but mingles them when actually stores them (the backend uses AD for authentication, but the password change goes through a custom web form).

And of course then logging in doesn't work at all. It took me days to figure out what was going on.

I have to avoid symbols and special characters when I have to renew my password there from now (luckily with pass it's just another command line switch).

Just use an ultra secure password schema such as September2019@$ . They obviously want you to use it considering that policy

Same here. Using a base password and adding the month in which I changed it the last time. If somebody feels happy about that, so be it.

I once tried Password1 scheme as a form of protestation for a client corp account I'd connect every 2 month or so but that had a 1 month rotation policy (so that I actually had to change my password every time I connected to them). It worked... Obviously I changed it to something else but regularly tried if still worked.

The big payout was when we had an on-site formation from a third party and the teacher needed to create a corp account. He miserably failed to validate various secure combinations against policy (like 16+ length 5 words xkdc style). Being the only consultant associated, I just yelled across the room full of in-house IT guys "Just try Password1 it's gonna make it!"

Obviously it worked out ¯\_(ツ)_/¯

PS: Oh and nobody reported me for this "incident" I still don't know if it's out of shame, dumbness or because nobody wanted to actually get to work to change that policy.

Oh yeah. Yeeeears ago, I was contracting for a telecom provider, and as a contractor, the process for getting logins to all the stuff I needed access to was onerous in some cases, nonexistent in others. So the employee who was sponsoring my presence in the building just said I could share his login. "The password is Apr1999!, if you happen to be the first one to log in when it expires, just change it to May1999! and so on, alright?"

It satisfied the uppercase, lowercase, number, symbol, and non-reuse criteria perfectly, while having precisely zero security.

Come to find out, something like a dozen different contractors were all sharing this one guy's login. He was the only reason anything got done in the whole region. The "system", such as it was, worked, but it made a mockery of corporate IT.

A few months into the project, that employee gave his notice and quit. Went to work for the competitor across the street; we'd bump into each other at the diner and stuff. But they couldn't just turn off his login -- his manager understood that all the contractors were using it, so they just left it active, and whoever got the expiry prompt would dutifully update the password every month...

>but it made a mockery of corporate IT.

Isn't corporate IT recursively defined as being a mockery of corporate IT?

If you make the system secure but unusable, the users will find a way to make it usable but insecure.

But changing the password every month doesn’t make it any more secure.

Passwords don’t really have an expiration date if they are secure (as in long enough and not reused) in the first place.

Why would you get reported?

I don’t know someone from this client could have called my boss and said that I was a disrespectful dipshit that compromised their reputation in front of a third party...

But I guess they also knew my boss would have laughed at them and said he support me. I have a great boss. I really can’t complain on that level.

> as a form of protestation

Me too. It's like a game: choose the easiest possible password given constraints.. My theory is: for each set of constraints there is always exactly one such password. Hard to prove, I know.

I use very secure passwords (32 character random) basically everywhere except for work because they are so aggressive about password rotation.

Work gets the equivalent of Banana1!, Banana2@, Banana3#....Banana9(, Banana1! (upper case, lower case, number, symbol, can't be previous 8 passwords) because we rotate constantly.

DROP TABLE

That seems like a system where the “password” `rm -Rf /` would...run.

Not a password but slightly related, had to use western union to send money for a friend last year and on their credit card page someone tried to be smart and failed, it checked for they key pressed to ensure only numbers but didn’t account for the fact that not everyone use QWERTY (on a French azerty you need to use shift to use the top row of numbers, without shift it’s accented letters and the like).

I kept thinking there was probably something in their tos pushing the blame on me if any issue happened since I had to bypass their security feature.

Just bad code where they took the actual key codes being pressed not the characters they map into, which made the code reject anything with shift pressed.

I regularly run into situations where my password on sign up is silently truncated (without being given a maximum char count) so at login I can’t just edit a field, I’ve got to guess how many characters of my password they actually use or reset it (and still guess).

The time entry system at my job disables the later days of the week (anything after tomorrow's day of the week) in the week when you try to enter your time the next week, even if you've manually selected the previous week. So on Monday Wednesday forward is disabled. So I need to run jQuery('input').removeAttr('disabled') in the console!

I had this issue with Air New Zealand - one of their sites was truncating the password field on one of the pages, but not on another page. Took me ages to figure out why sometimes I couldn't log in.

Auckland Transport does the same thing

E*Trade’s mobile app does the same thing, but you can’t edit the password field since it’s a native app. Website allows longer passwords than what their mobile app allows and just locked you out of your account after a few correct password entires. To make things worse, support tells you it’s due to your network.

My local bank made a new website that does something similar, where the input for creating the password is truncated to be shorter than the field for entering the password. I forget the exact length but it is pretty short, like 10 characters. It took me forever to figure out why I couldn't log in to their new site.

Reading this and other similar experience, I wonder if one could make a browser extension (or vendors implement on the browser) to warn the user when they are typing behind the maxlength.

I like this idea. It's a general enough issue that making it a browser standard could be quite nice.

Early versions of Bitlocker on Windows suffered from this.

I'll let you figure out how I know this :|

I'm almost positive LINE does this with their 20 char limit too.

The only reason I can figure why anyone would do that is if at some point the password in the db was a varchar with a length and then they changed it but didn't change the frontend - big isolated development team problems.

afaik, passwords are not stored in databases. Only the hash of the password is stored. The database doesn't know and doesn't care about the length of the password.

A human has to do the work to turn the password string into a hash and store the hash. At some point in time (or now, even), it's probable that they ... didn't hash the password.

Either the password or the hash of the password is stored, which it is depends on the age of the application, the skills of the developers and probably other factors that do not readily spring to mind.

However I am quite certain that not every solution has hashes of the password stored because every now and then I still get sites that tell me the password I chose has disallowed characters in it.

Reply on news.ycombinator.com