HN user

scarhill

596 karma
Posts53
Comments52
View on HN
brave.com 6y ago

Privacy-Preserving Product Analytics (P3A)

scarhill
1pts0
www.lastweekinaws.com 6y ago

AWS isn’t killing your business

scarhill
3pts0
philip.greenspun.com 7y ago

Boeing 737 MAX crash and the rejection of ridiculous data

scarhill
3pts0
coyoteblog.com 7y ago

Facebook Seeks to Leverage Its Own Failings to to Cement Its Monopoly Position

scarhill
1pts0
redmonk.com 7y ago

The Cloud and Open Source Powder Keg

scarhill
6pts2
time.com 7y ago

There’s a Larger Lie Beyond the College Admissions Bribery Case

scarhill
2pts0
philip.greenspun.com 7y ago

Less than a month to go before Google breaks links to Google+ Picasa albums

scarhill
100pts90
www.erosblog.com 7y ago

Google’s Digital Dementia: It’s Forgetting Stuff

scarhill
2pts0
blog.kamens.us 7y ago

CVS Fixes Security Hole Without Acknowledging Report about It

scarhill
1pts0
www.forbes.com 7y ago

Lesson from the A380 and California HSR: Smaller Is Better in Transportation

scarhill
2pts0
jmvdveer.home.xs4all.nl 7y ago

A brief history of Algol 68 Genie (2016)

scarhill
1pts0
www.bleepingcomputer.com 7y ago

Abandoned S3 Bucket Allows Malicious Script to Run on 800 Sites

scarhill
10pts1
www.rationaloptimist.com 8y ago

Electronic Cigarettes and Harm Reduction

scarhill
1pts0
hackingdistributed.com 8y ago

Online Signature Services Are Broken

scarhill
1pts0
arstechnica.com 8y ago

Fuze programmable payment card is open to data theft over Bluetooth

scarhill
2pts0
www.engadget.com 8y ago

Phantom Auto will drive your autonomous car if it gets confused

scarhill
2pts0
www.extremetech.com 8y ago

Latest MacOS Update 10.13.4 Breaks Multi-Desktop Displays

scarhill
5pts0
aws.amazon.com 8y ago

S3 One Zone-Infrequent Access, a New Amazon S3 Storage Class

scarhill
3pts0
github.com 8y ago

VanillaJS: Re-implement popular framework sample apps in vanilla JavaScript

scarhill
2pts0
www.nytimes.com 8y ago

David Reich Unearths Human History Etched in Bone

scarhill
28pts1
spaceweatherarchive.com 8y ago

The Worsening Cosmic Ray Situation

scarhill
156pts79
www.sacbee.com 8y ago

Founder of Tower Records dies at 92 while drinking whiskey, watching the Oscars

scarhill
5pts0
hackernoon.com 8y ago

Trying to see the inside of AWS’ data centers using AWS Device Farm

scarhill
1pts0
www.sec-consult.com 8y ago

A Long Way to a Vibrant Future – From IoT to IoD

scarhill
3pts0
www.chicagotribune.com 8y ago

Google's art selfies aren't available in Illinois

scarhill
1pts0
www.gnxp.com 8y ago

Preparing for Nero

scarhill
1pts0
www.bloomberg.com 8y ago

The End of Net Neutrality Isn't the End of the World

scarhill
2pts0
wiki.termux.com 8y ago

Termux: a terminal emulator and Linux environment for Android and Chromebook

scarhill
1pts0
blog.chromium.org 8y ago

Expanding user protections on the web

scarhill
1pts0
www.arnoldkling.com 8y ago

Post-Election Tech Guilt

scarhill
1pts0

His resume includes:

- FAA ATP AMEL and ASEL certificate with CL-65 SIC rating and Part 121 experience; CE-510S rating (single pilot, Cessna Mustang)

- Helicopter ATP

- single-engine seaplane rating at the commercial level

- FAA Flight Instructor certificate with airplane single-engine, airplane multi-engine, helicopter, instrument airplane, and instrument helicopter ratings

He has also worked as a commercial pilot for Delta/Comair. See https://philip.greenspun.com/flying/resume

Does knowing that you're running or contributing to Open Source code count? The AWS Open Source blog posted elsewhere in this topic implies that Elastic is making it hard to tell.

Making credential stuffing harder is the main reason to do this. Credential stuffing works because users reuse credentials across sites. If someone attempts to use a password from the HIBP database, the two most likely cases are that it's extremely common or the same person is reusing it. Extremely common passwords are bad for all sorts of reasons and the same person reusing a breached password makes the account vulnerable to credential stuffing.

Exactly. I think of the HIBP password list as having three types of passwords (this is an oversimplification, but bear with me):

1) Extremely weak ones that lots of people use (e.g. 'password1') 2) Somewhat unique ones (their pet's name and birthday) 3) Truly strong ones (random, long strings)

I don't want users on my site using type 1 passwords at all. If a password is really type 3, the odds say that no user will ever try to use it again, so there's no collateral damage in blocking it. The person signing up with a type 2 is almost certainly the same user whose credentials are in the breach. I don't want them to reuse that password on my site because it makes their account vulnerable to credential stuffing.

WRT the how could they get it so wrong question, I guess it's time for the obligatory link to Michael Crichton's essay "Why Speculate?" and his discussion of the "Murray Gell-Mann Amnesia Effect" [1]

Money quote: "You open the newspaper to an article on some subject you know well. In Murray's case, physics. In mine, show business. You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward—reversing cause and effect. I call these the "wet streets cause rain" stories. Paper's full of them.

"In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know."

1 - http://larvatus.com/michael-crichton-why-speculate/

If people don't know that LastPass has a 2FA app, they might think LastPass Authenticator is the password manager app, and is affected by this bug. As a matter of fact, a number of commenters seem to think exactly that.

As it happens, I switched from Google Authenticator to LastPass Authenticator a few days ago. The app has a feature that allows you to require a PIN or fingerprint in order to use it. That feature is disabled by default. (Note that Google Authenticator has no such feature.) As I understand it, this attack allows someone with access to my unlocked phone to install a activity launcher app and then generate 2FA codes without supplying a PIN or fingerprint. Actually, for my phone they wouldn't need to bother with the launcher app, because I didn't enable the additional fingerprint/PIN feature--it seems to reduce convenience while adding little security.

Still, it's definitely a bug. They should either fix it or remove the feature so people aren't misled into thinking their two-factor codes are secure when they're not.

According to the notification letters on that site, those three incidents all involve Google employees' information being leaked by third parties, not Google leaking users' data.

Here's a quote from one of them:

"We recently learned that certain hotel reservations made for Google business travel were among the many reservations affected by a security incident impacting a third-party provider’s electronic reservation system that serves thousands of travel agencies and hotels. This did not affect Google’s systems. However, this incident impacted one of the travel providers used by Googlers, Carlson Wagonlit Travel (CWT)."

The problem is adverse selection. If insurance buyers have information that insurance sellers aren't allowed to have or act on, high risk people will buy, while low-risk people won't. As losses go up, so will the price and when the price goes so high that only the highest risk people will buy, the market will collapse.

Not the author, but I think the proposal would be for browsers to not display scary warning pages HTTPS requests using self-signed certificates where the hostname is an RFC1918 IP address.

The argument is that self-signed certificates on internal-only IPs aren't any less secure than plain HTTP.