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

Lessons learned from cracking 2 million LinkedIn passwords

community.qualys.com

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Lessons learned from cracking 2 million LinkedIn passwords

#91

Post by [deleted] »

dkokelley wrote: post #18
ams6110 wrote: post #2

no matter how elaborate a password you choose, as long as it is based on words and rules, even if there are many words and many rules, it will probably be cracked So this is what I've been wondering about the current "best practice" to use long passphrases. How are those really any stronger than any other "rule" based password, the "rule" being that they are likely constructed of words and phrases from human language…

Well, calculating the "true" strength is difficult to do, because even though sophisticated tools are available to aid the process, the attackers are still human, and can input their own guesses that may or may not be more accurate. If the attacker knows (or can closely guess) the password rules used to generate your password, he or she has a better chance of getting a hit. Let's look at a password like "My first car…

[deleted]

Re: Lessons learned from cracking 2 million LinkedIn passwords

#92

Post by daliusd »

peterkelly wrote: post #88

So here's an idea: Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account. So what about an authentication mechanism that works as follows: 1. You type…

You are kind of reinventing BrowserID (https://browserid.org/).

Re: Lessons learned from cracking 2 million LinkedIn passwords

#93

Post by peterkelly »

daliusd wrote: post #92
peterkelly wrote: post #88

So here's an idea: Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account. So what about an authentication mechanism that works as follows: 1. You type…

You are kind of reinventing BrowserID ( https://browserid.org/ ).

Hehe, I was expecting to get an "X already does that" reply pretty quickly.

Surely this needs to be promoted more heavily to website developers, especially those behind major sites like linkedin. I'd never heard of it myself and I'm sure a lot of others haven't either.

If some of the bigger sites started adopting it, awareness would grow very quickly and we could greatly reduce the risks involved with every website storing password info for all their users.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#95

Post by exDM69 »

robomartin wrote: post #81
abraham wrote: post #38

Earlier quoted context omitted.

There are going to be much better discussions about this in Chromium discussion archives but I'll cover one of the main reasons why Chrome and Firefox (by default) do not have a master password. If someone has physical or remote access to your computer it is an endgame scenario and it does not matter if you have a master password enabled or not. The most basic attack is just to install a keylogger and steal the maste…

I understand this very well. Here's one scenario: Busy office. Hundreds of computers. Open environment (no doors, just a bunch of desks/tables). Everyone using Chrome. The current version of Chrome would allow someone to, within a few clicks, grab a pile of passwords. Here's another scenario: Your mother takes her laptop to be repaired/updated. She uses Chrome. The entire repair shop has easy, unencumbered access to…

If Chrome were to hide them in the UI, you could still get to them one way or another (like grabbing a memory dump). If someone has physical access to your computer when you're logged on, you've lost the security game. There's no point in adding a layer of obscurity on top.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#96

Post by tjoff »

peterkelly wrote: post #88

So here's an idea: Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account. So what about an authentication mechanism that works as follows: 1. You type…

I don't want to let server S know which sites I have an account to. Also, I don't trust server S.

And as if that wasn't bad enough (which it is) it is a single point of failure both in terms of security and availability.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#97

Post by peterkelly »

tjoff wrote: post #96
peterkelly wrote: post #88

So here's an idea: Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account. So what about an authentication mechanism that works as follows: 1. You type…

I don't want to let server S know which sites I have an account to. Also, I don't trust server S. And as if that wasn't bad enough ( which it is ) it is a single point of failure both in terms of security and availability.

The role of server S would be analogous to that of your email server, which you already trust. Just like email, it would be a decentralised system - with numerous public providers, as well as servers that organisations and individuals have set up themselves.

You could also have multiple accounts with different S servers, e.g. one for work and another personal use.

I agree with the single point of failure regarding availability - if your authentication server is down, you won't be able to log into anything. Though we already have the single point of failure with the existing system, in that once someone has your email password, they can obtain password reset messages from any site that you've registered on with that account.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#98

Post by benholmen »

LinXitoW wrote: post #90
saulrh wrote: post #71

Earlier quoted context omitted.

Just use keepass. If you're already carrying around a password file, you can carry around portable binaries of the program that reads your passwords. www.keepass.info

sadly, Keepass is not very Mac/Linux friendly, because it's built on .NET, so it's only an option for pure Windows users.

I use Keepass daily on Windows and Ubuntu and used it on OS X in the past without any issues. I highly recommend it.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#100

Post by tjoff »

peterkelly wrote: post #97
tjoff wrote: post #96

Earlier quoted context omitted.

I don't want to let server S know which sites I have an account to. Also, I don't trust server S. And as if that wasn't bad enough ( which it is ) it is a single point of failure both in terms of security and availability.

The role of server S would be analogous to that of your email server, which you already trust. Just like email, it would be a decentralised system - with numerous public providers, as well as servers that organisations and individuals have set up themselves. You could also have multiple accounts with different S servers, e.g. one for work and another personal use. I agree with the single point of failure regarding av…

So you gladly replace that single point of failure with two points of complete failure? You can't conceive of any problem with that reasoning?

You could also have multiple accounts with different S servers, e.g. one for work and another personal use.

If I was forced to use such a service I'd make a service that made it easy to automatically create one "S-server account" for each "real" account and continue to use passwords for those accounts as if nothing had happened.

In practice, BrowserID doesn't solve anything for me - at the cost of reduced security, availability and integrity - as well as forcing me put trust in a third party.

There is a huge difference between my mail server and the S server. If someone uses my mail to reset passwords I will notice, since my credentials won't work anymore. Also there are different levels of security, I value my mail account more than say my account on hacker news. Which I haven't even entrusted with my mail-address - love that you don't have to supply even a fake one and considering that I don't forget my password (or allow anyone to hijack my session) I can't possibly gain anything from supplying it.

Which is the key point, rather than me not trusting ycombinator there is just no incentive for me to supply it - so why should I? Maybe ycombinator gets hacked and my mail gets leaked, I might thus end up with spam - no need to take that miniscule risk when there is nothing to gain. Just as I see no reason to link independent accounts together with a service such as BrowserID.

Post reply on HN