Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password expiration is dead, long live passwords

techcrunch.com

Post reply on HN
Print view View original

251–260 of 316 posts

Re: Password expiration is dead, long live passwords

#251

Post by MichaelApproved »

_betty_ wrote: post #218
faceplanted wrote: post #217

Earlier quoted context omitted.

YouTube has this problem to an insane degree, some large businesses are run from a single person's long standing Google account and there's no way to give another YouTube account any privileges you might want an employee to have without giving them access to your entire Google account and all attached services including your emails, the ability to locate and wipe your phone, all the photos on your phone via Google ph…

Can't you just convert the channel to a brand account the associate new people? Has worked for us for years and afaik people don't have access to anything other than YouTube.

You can. OP simply doesn't know that feature exists.

Re: Password expiration is dead, long live passwords

#253

Post by discreditable »

asimops wrote: post #86
omh wrote: post #26

Earlier quoted context omitted.

How are you implementing these checks? I'm using Active Directory and options for extra password checks are somewhat limited.

You can use a dll to do additional security checks on a domain controller base. Check this https://github.com/JacksonVD/PwnedPasswordsDLL-API

The problem is the password change UI on Windows systems is terrible. It does not give users any clue why their password was not accepted other than "Unable to update the password. The value provided does not meet the length, complexity, or history requirements of the domain."

Re: Password expiration is dead, long live passwords

#254

Post by kurtisc »

thameera wrote: post #226
karrotwaltz wrote: post #193

Earlier quoted context omitted.

Not so long ago I had to register to a website allowing a comma (or was it a semicolon?) in a password during registration but refusing to login using said password. Fun times.

I once spent 15 minutes trying to register in a local Domino's website which kept bugging me about lack of a special character - even though I had one in it. Turned out to be that the app truncates the entered password after the first 20 characters and only considers the first part. Thankfully the special character was after the 20th position so I noticed the error and fixed it, but if it wasn't I'd be wondering the…

Why do you need a secure account to order pizza?

Re: Password expiration is dead, long live passwords

#255

Post by snarf21 »

mattowen_uk wrote: post #184

Shifting from passwords to more secure systems such as MFA ignores the elephant in the room about passwords that no-one wants to acknowledge: People share passwords. A simple example is this: A couple do online grocery shopping every week or so, depending who has time to do it, one them will log into the 'account' and build the basket. Maybe the other will then amend the basket a few hours later before the cut off ti…

MFA does not mean no sharing. It is trivial to setup up multiple credentials for the same account. You can easily have two different fingerprints setup as 2FA from two different devices for the same account. Most services let you have backup codes and dongles already. This is mostly an issue of education. We already see a lot of these kinds of other factors like sending a message to device 1 when provisioning device 2.

Re: Password expiration is dead, long live passwords

#256

Post by JoeAltmaier »

Not sure expiration is the worst problem with passwords. In no particular order,

* Most are easy to remember (most of us don't use LastPass etc)

* They authenticate the user but not the service!

* They're leaky (the system tells you when you have the wrong one, facilitating several kinds of attacks)

* People leave them lying around all the time

* Changing one almost always involves using the old one (instead of starting over from first principles)

Don't get me started on usernames! If you have a large hashed password, then the username becomes irrelevant (except as a way of leaking information).

Here's a modest proposal:

* Insist on large hashed passwords (256bit or better).

* Forget about usernames. The password becomes an 'account key' and is all you need

* Allow delegation: from one account to another; enable/disable features even for the 'main' account; give away authority for delegation at the feature level

* Never deny login for any reason, because that leaks security info (e.g. 'that password is illegal' is information). Just trust every legal password, and if it doesn't exist in the system then create a new default account

Re: Password expiration is dead, long live passwords

#257

Post by davedx »

malaysanghi wrote: post #159
lysp wrote: post #146

Earlier quoted context omitted.

The problem with having a short expiration is that it forces people to simply use their password with a count: password1, password2, ... password23, password24. This means that if you discover someone's current password, you also have their future 10+ passwords as well.

I would think anyone enforcing password expiration would make sure the password is sufficiently (subjective) different from current password. This should be simple to enforce by asking for current password when you are asking for new password. You can perform a text match before computing whatever hash you need to store.

Yep. I think I can recall exactly one corporate network that prevented password(n+1) combinations. Most don’t and as a result my corp passwords have historically not been great.

Re: Password expiration is dead, long live passwords

#258

Post by kurtisc »

discreditable wrote: post #12

I still expire passwords on a yearly basis for the sole reason that users have complained to me that it stops them from using the password they use for everything else.

If your profile is up to date: why are you including password reuse attacks in your threat model?

Re: Password expiration is dead, long live passwords

#259

Post by tomglynch »

loonyphoenix wrote: post #236
tomglynch wrote: post #213

Earlier quoted context omitted.

Well any website serious about security - yes. But if a single website decides to do it it would work fine. It would be quite easy to just add a js file with this. For example this one for the Stanford JS Crypto Library: https://github.com/bitwiseshiftleft/sjcl/blob/master/core/sh... We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.

How would protecting a single website help? If the password is shared among different sites, and one of the sites turns out to be malicious, I'll be able to access your single website just fine by typing the sniffed password into your textbox, whereupon it can use however much hashing and encryption as it wants and it won't help.

Ah I see what you're saying. You're right, in the interim period before everyone changes to client side hashing that is an issue. Though there's no loss to implementing it, but it's just not as beneficial until more sites have it.

For example: If there is no client side hashing: a user uses the same password for n websites. If one of the n websites gets hacked, an attacker can login to all n sites.

If one on site you have client side hashing: a user uses the same password for n websites. If one of the n-1 websites gets hacked, an attacker can login to all n sites. If the client side hashed website is hacked, the attacker can only login to 1 site.

Once each site has a unique salt, then we're secure.

Another issue is how can a website migrate over to client side hashing? I don't think there's an elegant way to do this.

Re: Password expiration is dead, long live passwords

#260

Post by jdmichal »

rahoulb wrote: post #222
reaperducer wrote: post #148

Earlier quoted context omitted.

A couple of years ago one of my banks "upgraded" its web site, forcing me to change my password to comply with its revised password guidelines since my old password was no longer permitted. The result was a password that was shorter, less varied, and less secure than the previous one. Good job, Chase.

I had a similar problem with Lloyds - every time I wanted to transfer money using the mobile app, I had to type in the password manually as they had disabled the "paste" option. Given my password was auto-generated and 16 characters long - and the password field wiped every time I did an app-switch, I just gave up.

I have a Keepass app on my phone, Keypass2Android:

https://play.google.com/store/apps/details?id=keepass2androi...

It has a keyboard bundled into it that will ghost type in the currently opened username and password. Works awesome for stupid stuff like your story.

Post reply on HN