101–110 of 134 posts
Earlier quoted context omitted.
My solution so far is: cat /dev/urandom|base64|tr -d '/+'|head -c10 Nearly every site supports a-z,A-Z,0-9 at 10 characters
Have you used pwgen before?
Earlier quoted context omitted.
My biggest pet peeve is how no one explains their password constraints until you break one of them.
I recently did a password change for some Apple site (iTunes, I think) and they handled this nicely. They put up a box beside the password field that listed the requirements, and as soon as I started typing it started dynamically changing the list to mark the requirements that my current entry did not meet.
$^$^$^_ = crack time 26 days $^$^$^i = crack time 3 months $^$^$^z = crack time 5 years Should the result vary so widely given the arguably minor variation?
n log (c)
for a length-n password with symbol space c. the huge difference in crack time is because zxcvbn is using c==33 (symbols only) for $^$^$^_ and c==59 (symbols + a-z) for $^$^$^z
$^$^$^i is in the middle -- 'i' is considered a dictionary match, the rest is c==59 bruteforce.
the bigger problem is $^$^$^ isn't recognized as a pattern, but i'm working on ways to improve bruteforce estimation too. good example!
Earlier quoted context omitted.
Does that break more then md5? I thought it was well known that md5 was a bad password hash algorithm.
I don't know why an application couldn't also attack other hashing algorithms. It's just about brute force creating lots of hashes. This app also uses GPUs to brute force TrueCrypt: http://www.golubev.com/igprs/
Length beats entropy every time. Steve Gibson has covered this before. https://www.grc.com/haystack.htm
SpinRite was great. Spinrite stopped being any use sometime in the early 90s.
Earlier quoted context omitted.
It always bothers me a bit when I see analysis of password strength for compromised sites without any mention of the possibility that the account might just not be important to users. But there is a caveat. If the account is somehow identifiable as yours (say, because your friends know it's your account) then suddenly it's a possible social attack vector. Perhaps a weak one, but probably not something to be ignored,…
> It always bothers me a bit when I see analysis of password strength for compromised sites without any mention of the possibility that the account might just not be important to users. I actually use that as a factor when considering a password. If I think the site isn't going to be the most secure (a phpBB forum, or hand-rolled web-app), then I'm more likely to use a simple (but still relatively decent) password.
Hmm, that is wrong enough that I'll call them out by name... https://www.nbotickets.com/ (Is it polite and useful to email them how I feel about that? I feel like I'd just be "someone-is-wrong-on-the-internet"-ing. Advice?)
Earlier quoted context omitted.
I recently did a password change for some Apple site (iTunes, I think) and they handled this nicely. They put up a box beside the password field that listed the requirements, and as soon as I started typing it started dynamically changing the list to mark the requirements that my current entry did not meet.
I just went through the iTunes "forgot my password" process and had a different experience. According to that box to the side, my new password passed all their requirements, yet on submit it kept rejecting it. I finally got it to accept a password when I stopped trying to use spaces. Are there other characters their back end rejects that the front end allows?
Quoted post unavailable.
Quoted post unavailable.