I think this came up and the consensus was that there are many other dos avenues, and the best solution is probably some sort of front end that filters stupid requests.

2FA only really matters if your password is already owned. So if you’re deriving the TOTP secret from the password, it’s not much better than storing it in the clear, right?

I would be surprised if you can pull even transferred packet counts off an iPhone.

Can you? Does anyone monitor that?

The biggest use case for wildcard certs is SaaS. If I have 10,000 SaaS customers with hosted domains like customer.example.com, LE wouldn’t want to issue (and renew!) that many certs. It also may exceed their rate limiter.

What are the risks for wildcard certificates?

I like supporting wildcards but I do wish they’d dramatically increase the rate limits and decrease the suspension time. Getting banned for a week after a fuckup or bug is nuts.

It’s not built by default. There is really no need for it in this situation, though — you can just basically send the gz files by themselves for certain locations, maybe modifying some headers slightly to explicitly indicate the encoding.

Typo: r/mechanicalkeyboards

Since the rule is almost entirely phonetic, this is actually quite common among people who have mostly read and written English and not spoken it much or at all.

There could also be potentially valid cases for paypal in a domain, like “dont-use-paypal.com” or “paypal-is-awful.com” or something similar. Someone may even want one of those domains to have perfectly valid SSL too.

[Comment removed by author]

You pose that as if they’re equivalent, but it’s not really the case, is it? Domain registrars have issued invalid certificates used for evil, yes. But is it quite so prevalent as with LE?

Years ago there were a lot of modems and network devices (routers, etc.) where the Tx and Rx LEDs (or equivalent) had sufficiently fast response times that you could actually read the data going through the device [cite]–no special software required.

The novelty is in leaking the information covertly with some sort of control. Observing a user’s screen isn’t exactly the same.

I read it as, SQL is insecure because bad developers will end up using it incorrectly.

That seems mostly reasonable to me. Using SQL in PLs where the default way to use it is by passing in ordinary strings that contain code is indeed insecure. Imagine if mainstream PLs had us defining and calling functions by calling eval() on strings all over the place: I would expect that to lead to terrific quantities of horrid security problems too. I accuse that passing a string to sqlite3_exec() or mysql_query()or PQexec() is equally as scary as passing a string to eval() because RDBMS query languages are either powerful enough to execute arbitrary code or complicated enough to inevitably have bugs that can be leveraged into arbitrary execution.

I’ve seen an interesting alternative in one of C J Date’s older books, “An Introduction to Database Systems”. He has examples of relational queries embedded directly into a language that looks like PL/1, where the queries are actually fully parsed at compile time. I think they had all the niceties, like references to ordinary lexical scoped variables in the queries turning into code that does all the correct binding at runtime and everything.

I’m thinking that one could make a much safer language be just as convenient as doing broken string concatenation is in current PHP, by using quasiquoting, reader macros or just straight up embedding SQL’s entire grammar into the PL’s own grammar in an expression context. I’d identify “PHP with mysql_query() replaced by quasiquoting” as a safer PL than “current PHP”.

Another strategy for making SQL injection harder to write by accident that I’ve seen is in the postgresql-simple library for Haskell. The query execution functions accept a string-like type called Query for which there is an IsString instance, so you can switch on the OverloadedStrings pragma and write code like execute connection "INSERT INTO dogs VALUES (? ?);" (name, cuteness) ­— so the correct, parameterised-query pattern is easy and convenient to write. At the same time, the incorrect string-concatenation code is still possible but much less convenient, so you’re much less likely to write it it. While you can build Query objects from strings, the syntax to actually do that is longer and involves looking up more stuff than the syntax for putting parameters in your queries.

IIRC there are also quasiquoters that let you write that as something looking like [sql|INSERT INTO foo VALUES (${name}, ${cuteness});] as an expression and automatically turn that into the above parameterised-query.

In all of the above, anywhere I refer to “PHP” you may instead read “any PL in which you use SQL by passing an ordinary string to a function or method with query or execute in the name”, i.e. very nearly all of them. PHP only does slightly worse than average here because mysql_query() comes bundled with the runtime but you have to install an ORM on purpose, whereas plenty of other PLs come with neither SQL bindings nor an ORM so it’s almost equally difficult to install the ORM or the raw SQL binding.

Two computers in separate space observatories, point the telescopes at each other and use maritime signalling.

She did say that the fix includes making the client code less trusting :)

At this point there are more 3-only libraries than 2-only libraries, and that’s only going to get more so. Beginners are better off starting with 3.

My thoughts exactly. If caching breaks my API, then I probably have a design flaw.

Passwords are pretty insecure. Most people reuse them. Compromising their password in one place (eg. Neopets) will allow you to assume their identity on most other services (Google, Facebook, Amazon, maybe a bank).

Passwords are absolutely broken.

LinkedIn was hacked 4 years ago, 164 million accounts compromised, and we just find this out in the past month?

Https? There’s no way to ensure that it’s even set up properly. The DROWN attack and heartbleed are both great examples. https://thehackernews.com/2016/03/drown-attack-openssl-vulnerability.html

Depending on any multi-use token for authentication should be considered poor security.

Hopefully it’s a lot faster than “hundreds of requests per second”, the stat touted on the site.

The author says he is planning to publish some benchmarks.