121–130 of 237 posts
Earlier quoted context omitted.
If you allow unlimited length, that a DoS attack. Ask the devs at Django
For which they set a 4K limit on password length. I think even the commenter you replied to would find that satisfactory, being much more than 64 characters.
Earlier quoted context omitted.
If your password is compromised, it will only work until the next reset. That's better than having one that works for years.
If your password is compromised, you've already lost. Since password rotation policies incentivize weak passwords, they are more likely to result in a compromised password. Thus, password rotation with weak passwords is not better than a single strong password that is never rotated.
Earlier quoted context omitted.
Many [1]. Some examples, my comments in parentheses: - Out-of-Band Authenticators (mobile app over secure channel) - Single Factor OTP Device (like an OATH push-button, enter 6-digit code TOTP device) - Single Factor Cryptographic Devices (insert into computer) (among others) [1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
Which is a real shame. SMS might not be perfect, but it's a real help when I don't have a better means handy. Its better than no 2FA, and it's saved my butt a few times when I get a text message saying "Here is your login code" and I'm out walking in the park. I get a new phone every year, and Google Authenticator sucks for that, but it's by far the second most common 2FA provider. I just got a new phone today, and h…
Earlier quoted context omitted.
If a salt matters, that means you can look it up in a dictionary of hashed passwords. Which means its in a very small search space. Which means a exhaustion search would find it quickly anyways. Far more relevant than "salts" would be using a PBKDF (See PBKDF2, SCRYPT, BCRYPT - which come with a salt for free anyways) with an appropriate number of iterations. What was the last year that Rainbow Tables were relevant a…
Even if you assume weak passwords, there's no comparison in effort when you involve stretching. No salt means you can precompute the hash for the 1,000,000 most common passwords. That'll take maybe an hour or two with aggressive stretching. Then you check it against the million or so records in the database for any matches. Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. Tha…
If you somehow get into a server with those hashed passwords, you'll probably try to mirror it and everything on the server, to figure out the hashing mechanism. So lets say, time is not an issue, also regarding long lasting APT's.
So what will you do with it? Why should you try brute force a million passwords, each one taking 2 hours to decrypt? No, you're smarter than that: Why not create a rainbow table of possible admin account, vips, state actor, etc. How many are those? 100? 1000?
Nice, you just reduced the search space by a factor of 1000.
That whole circus about hashing... I know, randomly salted hashing makes sense, but true secure password storage is a myth.
Earlier quoted context omitted.
If a salt matters, that means you can look it up in a dictionary of hashed passwords. Which means its in a very small search space. Which means a exhaustion search would find it quickly anyways. Far more relevant than "salts" would be using a PBKDF (See PBKDF2, SCRYPT, BCRYPT - which come with a salt for free anyways) with an appropriate number of iterations. What was the last year that Rainbow Tables were relevant a…
Even if you assume weak passwords, there's no comparison in effort when you involve stretching. No salt means you can precompute the hash for the 1,000,000 most common passwords. That'll take maybe an hour or two with aggressive stretching. Then you check it against the million or so records in the database for any matches. Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. Tha…
I think the point I was trying, and perhaps failing to make, is that the three PBKDFs - PBKDF2/BCRYPT/SCRYPT - all come with a salt anyways - so you don't really need to call them out.
What I guess I should have made explicit, (and I didn't) is that if all you are doing is a single round of a SHA - then adding a salt at the beginning isn't going to make that password any more secure. If it could fall to a Rainbow Table Lookup, then it will fall in pretty much the same amount of time to a password-cracker - on the order of milliseconds.
Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
My password wound up being "4444444". Was always a little mystified that I could hammer out seven 4's without counting them faster than I could remember that I was at a suffix increment of "10" or "11".
Earlier quoted context omitted.
Replying to sibling. Worse, if reps can see the answer, then this is equivalent to not hashing the passwords at all since you have a password-equivalent stored in plaintext.
FYI, if you click on the minutes ago link above the post you can get a reply box even on new posts. When I worked for t-mobile it was last 4 of the social unless the customer requests otherwise. Few requested otherwise, and usually it was because they were annoyed about people being able to see part of their SSN.
Part of? I worked for AT&T back when they merged with Cingular. We only asked for the last 4 over the phone, but the entire 9-digit SSN was shown in the app. Every single low-level employee had (has?) the entire SSN in front of them. Never dared tell a customer that little fact when they made a fuss over my having access to their last 4.
Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
We have a script that updates our passwords for some automated processes. So let's just increment a number inside the password every month with some perl! /^(.*?)(\d+)(.*?)$/
$ echo abc9def | perl -pe 's/(\d+)/$1+1/e'
abc10defI've written into several companies in the past saying "your password policy are bad for __ reason", and they always of course write back saying basically "our security team doesn't care, shut up". There've been quite a few times I've cancelled accounts right after signing up because of just how absurd they were (for instance I believe Trade King forces you to click type your password with the mouse on an on-screen k…
I've written into several companies in the past saying "your password policy are bad for __ reason", and they always of course write back saying basically "our security team doesn't care, shut up". There've been quite a few times I've cancelled accounts right after signing up because of just how absurd they were (for instance I believe Trade King forces you to click type your password with the mouse on an on-screen k…