And we get back to the original point of the article (sort of). Opening a magic link should authenticate the user who opened the magic link, not the attacker who made the application send the magic link.
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.
I'm a security researcher - no quotes. I write detailed, highly technical write-ups for all of the issues I discover, including reproduction steps, root cause analysis and suggestions for fixes. I follow all responsible disclosure guidelines + any guidelines that the company or entity might have for security disclosures.
It's disheartening when you put this amount of effort into it, it gets silently patched, and you get no recognition or even a "thank you". But I don't let it bother me too much. I'm doing this research mostly for myself and because I find it interesting. The fact that I'm disclosing the issues is me being a good citizen, but I shouldn't expect a pat on the head for every issue I disclose.
Being ignored always sucks. But it's still infinitely better than doing all of the above and being threatened with a lawsuit (which has, unfortunately, happened as well).
Building the next update locally is slow because erofs has to compress the entirety of /usr on my rather old laptop and that takes a while.
Aside from that, I'm using flatpak for firefox and for some reason it takes absolutely forever (like > 15s) to start firefox on my machine, still need to look into why that happens.
Aside from those it's very usable. But of course it's running systemd from source so I'm not going to actually recommend anyone to run this who is not a systemd maintainer until we iron out the kinks.
I'm not sure if I miss IRC, or the simpler times that were when I was actively on IRC. Maybe it's a bit of both. But there's definitely some niceties in modern messaging applications that you can't get in IRC.
I was curious about the same thing, and found the following from Dave:
> I had to deal with that analogy a lot in high school, and I got used to it. It is, indeed, a rather popular food in schools. My problem with people using TAYT is that they end up misspelling it as Tate. Actually my name in the USA is usually pronounced "Tot", or better, T"ah"T, but while doing i18n testing in the mid-90s, and I discovered that the correct spelling (in Estonia) was with the ä. I gleefully adopted that, so I could break all of our protocols and web tools prior to the worldwide acceptance of UTF-8, and also because I was a death metal fan. Using the umlaut also makes it impossible for an automated spellchecker to respell it as "That", however no alternative has really worked. For a while there, the IRS thought I was three different people....
> The word, in Estonian, means "Star or planet", and as the Estonians did not know what an asteroid was, I have taken it to mean "Star or planet?".
While not saying anything about roots directly, I'm guessing it has to have been the reason behind him adopting the Estonian spelling of it. Maybe from grandparents or great-grantparents. Or even further back, considering apparently Estonians didn't know what an asteroid was back then.
The word "täht" itself means "star" (both celestial one or a notable person) or "letter/glyph", not "planet".
> Or even further back, considering apparently Estonians didn't know what an asteroid was back then.
Asteroids have been called "falling stars" in most languages for ages, nor would "asteroid" work well as a name. Nothing to do with anyone's knowledge of astronomy really.
I don't see how the two projects are related, so there shouldn't be any confusion. The project you linked isn't even called chibi, it's called chibi-scheme. If you suggest that we should not use common words in our project names if those words have been used before, we would've run out of names long ago.
Out of curiosity, what is the answer? From your comment, it seems like the more obvious choice is the incorrect one.
EDIT: By the more obvious one, I mean letting it cool and then adding milk. As the temperature difference between the coffee and the surrounding air is higher, the coffee cools down faster. Is this wrong?
That is the correct answer. Also there is a lot of potential nuance, like evaporation or when you take the milk out of the fridge or the specific temperatures of everything, but under realistic settings adding the milk late will get you the colder coffee.
Does the ceramic mug become a factor? As in adding milk first allows the milk to absorb heat that otherwise would have been stored in the mug too quickly and then radiate back into the liquid over time slowing its cooling curve. (I have no idea btw I just enjoy trying to come up with gotchas)
I'd say adding milk late is the best. You have coffee with volume and heat V and Q, milk v and q. Whatever you do, you'll get volume v+V and heat Q+q. Q can become Q' if you let it cool down first, or (Q+q)' if you add the milk first then let it cool down. But because milk is cold, the Q/V > (Q+q)/(V+v), hence the loss Q -> Q' is bigger than (Q+q) -> (Q+q)'.
The best answer though is to put the coffee on a plate, and forget about the milk.
Isn't the answer milk first, then let sit? You only have 2 minutes, so if you're adding the milk after 2 minutes have already elapsed, then you've already exceeded the time limit, meaning the final measurement would take place before the milk is even poured in.
The bigger the temp difference the more cooling. So by putting the milk in right away you make the temp difference between the surroundings and the coffee smaller = less cooling over your 2 mins.
