101–110 of 168 posts
Had to look it up - unrelated to okcupid. For those interested, here's a list of their web properties: http://www.cupidmedia.com/services.cfm
2. There are a lot of specialty dating sites out there.
What this story shows is that sometimes '12345' makes sense as a password - i.e. when credential security doesn't matter to the user. If I use '11111' to sign up for a onetime visit to a website, then there's no nexus with my online banking account other than an email address - assuming even the most feeble attempt at picking a 'secure' password for my banking. This is why it is often silly when articles condemn user…
Earlier quoted context omitted.
A browser plugin that pre-hashes anything in a hidden text field (with a user secret key and the password origination domain) could mimic this as a layer on top of existing technology. It would have the obvious portability issues, and I'm sure other implementation issues.
Your idea sounds like an automatic version of SuperGenPass: http://supergenpass.com I've been running it for years, which feels quite nice when sites start leaking passwords left and right.
Thank you for sharing, I am going to download this immediately. My current algorithm for passwords is human based so it is an unfortunately simple algo. It provides some additional security over raw reuse but not enough for me to be comfortable.
Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…
I agree, trusting remote services (and the communication infrastructure in between) is naïve. Meanwhile, I use KeePass and generate a different key for each service.
What this story shows is that sometimes '12345' makes sense as a password - i.e. when credential security doesn't matter to the user. If I use '11111' to sign up for a onetime visit to a website, then there's no nexus with my online banking account other than an email address - assuming even the most feeble attempt at picking a 'secure' password for my banking. This is why it is often silly when articles condemn user…
Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…
It's interesting that no one's pointed out that SRP is trivially breakable by having the client send zero as its "A" value. Of course, you can guard against that particular case. But the point is that SRP has pitfalls, just like every other solution. And those pitfalls aren't well known; the Wikipedia pseudocode makes no mention of that exploit, for example.
1. Carol will abort if she receives B == 0 (mod N) or u == 0.
2. Steve will abort if he receives A (mod N) == 0.
3. Carol must show her proof of K first. If Steve detects that Carol's proof is incorrect, he must abort without showing his own proof of K.
[1] Ok, the python code doesn't seem to, you're correct. However, that's less a demonstration of a protocol implementation, and more a demonstration of the protocol's math. The page does mention it though in the protocol section. It would be appropriate (and maybe later I'll do this) to break that out so it's more obvious.
Earlier quoted context omitted.
well, you could even do it manually echo 'this is my pass' | shasum 3b0c5dc943cd30dcd2ca1ff760145f219d3ba3f3 And use that as the password. Of course, this is a very basic example, you should make it more safer by adding a salt and running more iterations. May be easier (and safer) than installing "One password" kind of software.
That doesn't quite work in the unfortunately common case of user password re-use. If your hash is constant and stored in plain text somewhere and that place gets hacked -- then your password at every site is compromised.
Earlier quoted context omitted.
"The answer" doesn't exist and it never will. Everyone has to do their part. Services that store passwords in plaintext should definitely be publicly shamed, every single time.
The problem is that "publicly shamed" means "shamed amongst security geeks". Most websites main demographic is not security geeks.