What's quite annoying is how agressive most products are into forcing this method over regular email+pw / Social Logins. Let me use my 100 chars password!
You are not the target audience, you are not even an outlier, it's probably time to accept this and look for long-term solutions that allow you to interface with the "mainstream".
Agreed. But since every character gives you around 6 bits (26*2 letters + 10 numbers + some special characters ≈ 64 = 2^6), you'd need 256/6 ≈ 43 characters to exhaust the checked entropy, so up to that level it makes sense.
If you use sentences instead of randomly generated characters, the entropy (in bits/character) is lower, so 100 characters might well make sense.
Passwords are (or, rather, SHOULD be) cryptographically hashed rather than encrypted. It's possible to compute a hash over data which is longer than the hash input block size by feeding precious hashes and the next input block back in to progressively build up a hash of the entire data.
bcrypt, one of the more popular password hashing algorithms out there, allows the password to be up to 72 characters in length. Any characters beyond that 72 limit are ignored and the password is silently truncated (!!!). It's actually a good method of testing whether a site uses bcrypt or not. If you set a password longer than 72 characters, but can sign in using just the 72 characters of your password, they're in all likelihood using bcrypt.
It's not broken. It's just potentially less helpful when it comes to protecting poor guessable passwords. bcrypt isn't the problem, weak password policies/habits are. Like bcrypt, argon2 is just a bandaid, though a tiny bit thicker. It won't save you from absurdly short passwords or silly "correct horse battery staple" advice, and it's no better than bcrypt at protecting proper unguessable passwords.
Also, only developers who have no idea know what they're doing will feed plain-text passwords to their hasher. You should be peppering and pre-digesting the passwords, and at that point bcrypt's 72 character input limit doesn't matter.
Bcrypt alone is unfit for purpose. Argon2 does not need its input to be predigested.
It's easy for somebody who knows this to fix bcrypt, but silently truncating the input was an unforced error. The fact that it looks like and was often sold as the right tool for the job but isn't has led to real-world vulnerabilities.
It's a classic example of crypto people not anticipating how things actually get used.
Peppering is for protecting self-contained password hashes in case they leak. It's a secondary salt meant to be situated 1) external to the hash, and 2) external to the storage component the hashes reside in (i.e. not in the database you store accounts and hashes in). The method has nothing to do with trying to fix anything with bcrypt. You should be peppering your input even if you use Argon2.
Right, but peppering was not part of my comment. You can't always pepper, and there are different ways to do it. It's (mostly) orthogonal to the matter.
You do not have to do any transformations on the input when using Argon2, while you must transform the input before using bcrypt. This was, again, an unnecessary and dangerous (careless) design choice.
I don't understand your responses here. Clearly you are not familiar with what problem peppering solves, or why it's a recommended practice, no matter what self-contained password hashing you use. bcrypt, scrypt, Argon2; they are all subject to the same recommendation because they all store their salt together with the digest. You can always use a pepper, you should always use a pepper, and there's only one appropriate way to do it.
And no, you cannot always pepper. To use a pepper effectively, you have to have a secure out-of-band channel to share the pepper. For a lot of webapps, this is as simple as setting some configuration variable. However, for certain kinds of distributed systems, the pepper would have to be shared in either the same way as the salt, or completely publicly, defeating its purpose. Largely these are architectural/design issues too (and in many cases, bcrypt is also the wrong choice, because a KDF is the wrong choice). I already alluded to the Okta bcrypt exploit, though I admit I did not fully dig into the details.
The HMAC-SHA256 construction I showed above, and similar techniques, accomplishes both transforming the input and peppering the hash. However, the others don't transform the input at all or, in one case, transform it in a way even worse for bcrypt's use.
Using memorable passphrases online is always a bad option because they're easily broken with a dictionary attack, unless you bump the number of words to the point where it becomes hard to remember the phrase. Use long strings of random characters instead, and contain the use of passphrases to unlocking your password manager.
To wit, each word drawn from a 10,000-word dictionary adds about 13 bits of entropy. At 4 words, you have (a little over) 52 bits of entropy, which is roughly equivalent to a 9-character alphanumeric (lower and upper) password. The going recommendation is 14 such characters, which would mean you'd need about 7 words.
The average person will create a passphrase from their personal dictionary of most-used words, amounting to a fraction of that. An attacker will start in the same way. Another problem with passphrases is that you'll have a hard time remembering more than a couple of them, and which phrase goes to what website.
Very interesting take and definitely an article I will come back to, but in the end, the size of tasks is relative, and the author counts them. How's that better than counting story points? Feels like a lot of folklore for a similar result. In the end, like with story points, what matters is the effort put into splitting a problem to better understand it and plan accordingly.
I recently purchased a Synology with 2 disks in raid 1 to backup all my Google Drive, all my Google Photos files continuously.
I feel much better since doing this (apart, of course, for the fact I now need to back up my Synology too to really feel good!)
And for those who think Google Takeout is there to save you, just bear in mind it can be very erratic with large volumes (I had the biggest pain to get my Google Photo despite taking out less than 200 gb, it took several tries to have all the files)
No one is safe against account issue, or as it seems to be the case in the help thread, pure data loss. Just back things up and rely on cloud for flexibility rather than storage.
I've been doing Google Takeout backups to Synology for a while. Curious is you or any other users have an automated way to do this instead? So an automated way to backup Google Photos to Synology.
What other raid could he have on a two drive NAS? I have the same setup at home with some push to the cloud and have the peace of mind that if one drive fails I can recover from it with a rebuild of the other drive
- Jan to June on one row
- July, August September in a column under June
- October to December on one row, which is on the same row or next year's Jan.
1) Some front end needs and/or frameworks were developped by companies having a scale and pool of talent justifying the needs for new tools tailored to their use cases (extreme audience = need to address many user specificities + pool of talents means the best brains on this planet invent something: doesn't help in coming up with a trivial solution). React, Flutter, AMP.
2) During the zirp, coming up with some great tech was also a way to attract talents. Using such tech was (is) a way to be part of that group too. There is a trend effect. I am wondering whether complex front end tech stacks are justified when you can't hire the best talents and when you need to work faster to keep in business.
3) Micro service all the things leads to using API's everywhere which leads to have consumers everywhere including your front end. Coming back from this could mean using simpler apps and dropping some of the front end complexity.
What gig? Making a game? Becoming a freelancer? That just means working even longer and without holidays and other benefits.
My current office job allows me to not think about work after 18:00. And I can simply delete slack from my phone when I go on vacation.
Feels like a problem that will be solved as soon as incentives will be here, and cost of fresh water from other sources depleted or protected. The costs mentioned in this 15 years old article aren't that high in a world where we have to be careful with water.
