Don’t Get Clever with Login Forms • Hacker News Board

Re: Don’t Get Clever with Login Forms

#371

Post by int_19h » Sat, Feb 16, 2019, 1:26 AM UTC

013a wrote: post #324

> don’t split login across multiple pages This is often necessary for enterprise applications; what they're often doing is making an intermediate request once they have your email address to determine how you log in. Do you use a password? Do you use SSO? If you use SSO, is it SAML? Do you have multiple accounts? Here's my experience, as an engineer at an enterprise company. We tried to put everything on one page, an…

> The number of people using password managers is literally a rounding error.

Given that they're present out of the box in all major browsers, I find it hard to believe. Maybe it's true for the user base of that enterprise app, but on the web as a whole?

And Chrome particularly is very aggressive at pushing the password manager. It will detect login forms and ask to remember passwords even without people interacting with it at all. It will offer to pre-fill a login form as soon as you start typing your login.

And recently, it's even offering to auto-generate strong passwords when it sees what looks like an account registration form - and those passwords then get saved straight to the password manager, so any person that takes the easiest route and clicks "OK, sure" is going to be tied to said manager thereafter.

Re: Don’t Get Clever with Login Forms

#372

Post by int_19h » Sat, Feb 16, 2019, 1:27 AM UTC

scarmig wrote: post #356

da_chicken wrote: post #316

Earlier quoted context omitted.

I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

A use case where disabling paste events makes sense: You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars. Text specifying what they're doing is insufficient, as us…

If you need to do something like this, do it separately from the actual input. For example, something like "type in the name of the account you're trying to delete".

Re: Don’t Get Clever with Login Forms

#373

Post by kccqzy » Sat, Feb 16, 2019, 1:28 AM UTC

zachberger wrote: post #335

labster wrote: post #274

Earlier quoted context omitted.

It's easier to just hack the HTML IME. If pasting is blocked in JS, and the site has a (probably ancient) version of jQuery installed, just throw this in the console: $('*').unbind('paste');

This is great, but not easy to get into a console on mobile. I always struggle with United Airline's wifi which prevents paste, and I always try to access from mobile.

You can use a bookmarklet. I don't have one for restoring paste, but I have ones for setting viewport width to desktop and it works really well (iOS Safari).

Re: Don’t Get Clever with Login Forms

#374

Post by int_19h » Sat, Feb 16, 2019, 1:29 AM UTC

siedes wrote: post #347

nojvek wrote: post #338

Earlier quoted context omitted.

Ha. Right click -> inspect element. In dev tools console. $0.value =“password”. I use that in reverse when I can’t remember a password. Get the value from input element gives the browser remembered passwords. Works on other peoples machines too. If you wanna steal remembered passwords. That’s how chrome extensions steal passwords. Just sayin.

Someone debunk this so I can sleep at night.

What is there to debunk? Someone who has access to your browser, has access to all your browsing data - of course! This includes saved passwords.

Re: Don’t Get Clever with Login Forms

#375

Post by kccqzy » Sat, Feb 16, 2019, 1:38 AM UTC

guitarbill wrote: post #93

argd678 wrote: post #11

My list: 1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. 3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code 4. If you login to any 3rd…

5. Don't force password rotations. 6. Don't force me to use certain character classes if my password is long enough and therefore entropic enough without them. Special characters suck and are inconsistently supported.

At work I once proposed a solution to address 6. Basically we want to accept either a short password with many different character classes, or a long one with just lower case (or something similar). We tried a prototype where we used zlib to compress the password and measure the compressed length as a proxy for its complexity. I really liked this solution but we didn't adopt it because it's literally unexplainable to normal users.

Re: Don’t Get Clever with Login Forms

#376

Post by contravariant » Sat, Feb 16, 2019, 1:38 AM UTC

scarmig wrote: post #356

da_chicken wrote: post #316

Earlier quoted context omitted.

I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

A use case where disabling paste events makes sense: You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars. Text specifying what they're doing is insufficient, as us…

Disabling copy paste on the field that specifies the resource isn't a solution though, as that only increases the risk of typos.

Re: Don’t Get Clever with Login Forms

#377

Post by kccqzy » Sat, Feb 16, 2019, 1:41 AM UTC

Sammi wrote: post #291

ben509 wrote: post #184

Earlier quoted context omitted.

You have to get the data out of the text form. Unicode passwords mean all text entry forms on all browsers using all operating systems must be returning identical data, or at data that can be normalized to be bitwise identical without discarding the accents. While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of…

Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.

Differences in for example, NFC or NFD forms of text, which is relatively common. And even for UTF-8, certain platforms don't properly encode code points beyond the BMP; they do it by encoding to UTF-16 surrogates and encoding the surrogates separately.

Re: Don’t Get Clever with Login Forms

#378

Post by jtms » Sat, Feb 16, 2019, 1:44 AM UTC

joshuaheard wrote: post #272

Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

Yeah the disabling of paste into the password field is super annoying. My work around is to open the developer console and paste into a js one liner that sets the value of said form field. For me it’s slightly better than the tedious manual entry and I get to wave my fist at the screen in self righteous indignation: “no one tells me when I can and can’t copy/paste!”

Re: Don’t Get Clever with Login Forms

#379

Post by jechamt » Sat, Feb 16, 2019, 1:49 AM UTC

nojvek wrote: post #337

argd678 wrote: post #328

Earlier quoted context omitted.

There needs to be a standard or something here to facilitate password mangers. Everyone should be using one and not reusing the same password.

I hate password managers with passion. In general passwords are hard to remember. Especially when every site has their own requirements. Password managers add too much friction. I very much like login in with google. Even two factor TOTP is nice. I don’t have to remember things. I just need to carry a device with me.

I really think it's counterproductive to downvote posts such as this one. Effective security absolutely must be based around user experience - your application needs users, and if you give them friction, they will vote with their feet. It's not about an emotional decision or stubbornness or unwillingness to learn, it's a statistical inevitability.

I'm confident experienced security professionals know this idea well: I'd posit that no one hates passwords more than the person who has to design the training explaining to everyone why they need to use unique passwords, of a certain length, of a certain complexity, and how the risk behind those changes in different environments. I hope mostly everyone would agree passwords are a terrible security solution. So if somebody wants to post that's how they feel about this, and their experience with a solution to get away from passwords, or minimizing them, let's have a discussion about what better options are out there (as some have already done in this thread).

In my view, the most important posts in the discussion of user-accessible security management are these posts that identify what makes every user need to be a hashing expert to select and manage the ever-expanding repository of account credentials we have today.

Re: Don’t Get Clever with Login Forms

#380

Post by jtms » Sat, Feb 16, 2019, 1:49 AM UTC

qrbLPHiKpiux wrote: post #287

labster wrote: post #274

Earlier quoted context omitted.

It's easier to just hack the HTML IME. If pasting is blocked in JS, and the site has a (probably ancient) version of jQuery installed, just throw this in the console: $('*').unbind('paste');

We're talking about the general public! Can you imagine the phone conversation I would have with my dad about this? It would end in WW3.

router passwords taped to the back of the router is about as sophisticated as the “password management” gets for mine (or hand written on a random page of a 99 cent spiral notebook)