I made something similar as a fun little project https://github.com/mrmagooey/taboo, does the same print function but also does some basic querying, deletes and updates, left and inner joins. I had no idea that the inbuilt version existed though.

The paper reports:

> Colorado’s legalization of recreational cannabis sales and use resulted in a 0.7 deaths per month (b = −0.68; 95% confidence interval = −1.34, −0.03) reduction in opioid-related deaths.

Which if I understand right, they're pretty sure it did something, but that something might be so small that the value of reporting it is negligible.

That seems to imply causation. I am skeptical.

Don't get me wrong, I smoke a lot of pot. I don't do so for health reasons. I just like smoking pot.

The default position I hold is skepticism. There have been some less than truthful claims of efficacy and curative properties.

I'm very much pro legalization. The medicinal benefits have no bearing on this opinion.

> If there's a serious vulnerability that actually needs your attention, you will read about it in the news

The ol' security through tech press approach. Seriously though, you can't have the security of your devices dependent on whether or not someone has come up with a catchy name for their exploit. The exploits with names like broadpwn and stagefright are the exceptions, not the rules, there are plenty of critical CVE's that have never had cool names or tech articles written about them. Even if an exploit has a cool name and some press, what if people don't upvote it when it gets posted here (or reddit/wherever)?

You seem to think that a security hole being "critical" implies you need to care about it. You do not. You only need to care about actual threats, not mere security holes. A "critical" CVE that nobody exploits is pretty darn pointless to worry about, just like how the fact that cellular communication is plaintext isn't really tickling too many people because the average criminal isn't using a Stingray. And an expoit that becomes widespread will get the press attention, precisely because people will want to know about it. (Unless you're the kind of person who's always one of the first few to catch a virus, in which case either you're a security researcher, or you're looking for trouble, or you're hanging out on the wrong networks...)

>And an expoit that becomes widespread will get the press attention, precisely because people will want to know about it.

As you're clearly entirely clueless about security, how do you know this?

If you primarily get your security news via the press, how do you know that they aren't simply missing most things?

Isn't JWT a modern alternative to CSRF tokens?

It's not. If you think it is you probably store JWT unsafely instead of in an httpOnly secure cookie.

Why do you think storing JWT in secure cookie is only secure solution?

Aren't passphrases kind of a bad choice for passwords? If all you are ever really guessing is the symbols that make up someones password, and you know that for example they have 4 words that make the passphrase, then you effectively only have to iterate 4 symbols with a known list of possibilities for each symbol (i.e. the dictionary).

If you compare the permutation space of a short passwords (length 7) with random characters (say ~80 potential symbols), with a long(er) password made up of 4 english words (say ~3000 potential symbols, the most commonly used english words).

    character_symbols = 80
    word_symbols = 3000
    number_of_character_password_symbols = 7
    number_of_word_password_symbols = 4
    permutation_space_characters = character_symbols**number_of_character_password_symbols
    permutation_space_words = word_symbols**number_of_word_password_symbols
    print('%.2E' % permutation_space_characters, '%.2E' % permutation_space_words)
    ('2.10E+13', '8.10E+13')

The words space is four times bigger, but in the same magnitude as the short (bad) password. I'm not an expert here, so I might have stuffed it up, but it seems like passphrases shouldn't really be encouraged?

I do love the recommendation to remove time-based password expiry though.

Yes, 80 ^ 7 has the same order of magnitude as 3000 ^ 4. But passphrases are recommended because many folks can memorize a passphrase more easily than a password of equivalent complexity. Or because a typical user's idea of an okay password ("Johnny88") has less entropy than a passphrase.

Passphrases are unnecessary for users with a password manager, except maybe for the manager's master password.

Everything in the article is spot on, I only wish they went further and recommended passphrases more strongly. It's correct horse battery staple and all that.

As for your calculation, you are about right. Except memorizing a completely random 8 character password drawn from an 80 symbol alphabet is /extremely/ unpleasant for most people, especially when you may have a few different passwords you use on a daily or weekly basis. And for passphrases, 6 words drawn from a 4096-word dictionary is typical. I use that setting (or even 8 words for more important things) and have easily memorized about a dozen passwords, even ones I use only once every few weeks.

40966 = 4.7e21, about the same as an 11-character random password.

So you have memorized the equivalent of a 60-word nonsensical poem?

Well, you only need to memorize the passphrase of your password manager's file.

What we should really talk about is the password entropy like what you've done.

If you take the xkcdpass package from Ubuntu, it uses a word list of 41230 words by default [1]. That's 41230^4 and about 61-bit of password entropy. If you want to use a smaller word list, add words to the passphrase until you reach a desirable password entropy.

Using your example of 80^7 for random characters, that's only 44-bit password entropy. So in this case, xkcdpass gives you a stronger password with just 4 words. If you want to reduce the word list to 3000, just add 1 more word and it's 46-bit password entropy. A decision between 7 random characters vs 5 words.

I personally prefer random characters because you can up the entropy significantly, and I have no problem remembering random sequence in the mid-teens range. That can easily get you 90-bit entropy or more. Everything else is saved in my password manager and there you can up the entropy even more. My auto-generated passwords are usually around 200-bit entropy.

  [1]: https://github.com/redacted/XKCD-password-generator

> I personally prefer random characters because you can up the entropy significantly

Isn't it far easier to up the entropy of a passphrase, though? Unless your password is using the entire Unicode character set, adding a word to a passphrase is going to give you better entropy than adding a character to a password, and it will probably be easier to remember since you can - reasonably safely - give it contextual meaning.

Now use a couple words not in the top 10,000. Suddenly your complexity goes waaay up.

How do you know how many words are in the passphrase?

You don't I guess, I'm just using 4 as an example (it's also the number of words used in xkcd's password strength comic).

I only ask because a different answer will change the math drastically.

No it doesn't. Your password has as much entropy as it has, and no more.

If you want to follow that train of thought to its logical conclusion, your attacker not only doesn't know the length of the password, they don't know what character sets make up the password either, and so you could claim that a 4-character numeric password is equally secure to a 64-character Unicode password. In fact by inductive reasoning 4-digit password could be said to have pretty much any finite amount of entropy, because how does the attacker know that it's not actually length N+1?

Yes, the attacker not knowing exactly what the password class is (words/character set/length) does help somewhat in a practical sense. But it doesn't "change the math" at all, if you have 3000 symbols (words) and your password is 4 of them then you have 3000^4 possible passwords. You don't get to count passwords that are not in your password class as part of your entropy.

I didn't mean math in general, I meant the math used in the post I was responding to, which had some unfounded assumptions. I can make assumptions too with vastly different outcomes, I'm sure that 10 random unrelated words are more secure than 10 random unrelated characters.

Could we not?

That thing was parroted a thousand times already and it really boils down to a personal rant about tons of legacy features rather than a properly worded criticism of the language itself.

The author is also really confused about type coercion in PHP.

It's been almost 5 years. Let it go.

Use this:

www.phpsadness.com

It's a useful reminder that how ever far PHP has come, it still has a long way to go. Most of what's in that post still applies today, though a few things have been dealt with.

A sample of two very short term rentals is an awful way to judge cars on long term traits like reliability.

This is a common error message for a number of CMS's (in this case probably WordPress) when overloaded, and shouldn't reflect upon the validity of the source.

Is there a concern that the mechanism allows for DoS? How do they mitigate the situation that the author describes?

If you have standard compliant hardware, pause is point to point, not broadcast. You can configure hosts to ignore pause and also to not generate it; although it may be difficult to configure an embedded device, so you probably need to fix the switch or replace it with something that works.

Accidental pause frame DoS has been observed in the wild and AFAIK there's no known solution.

There's several hundred Y Combinator companies, but I don't think I've seen a commensurate number of posts to HN. You'd know if it was open slather on Y Combinator companies posting self-promotion material to HN because this post would not be at the top, it would be some launch page for a company ending in 'ly'.

I typically only notice YC companies mentioned here when it is a Techcrunch (or similar) article about them.

I wouldn't have thought the GC would be expensive enough to warrant turning it off, interesting thought though.