HNHacker News
TopNewBestAskShowJobs

garrettr_

841 karma · joined March 23, 2015

submissionscomments
garrettr_··on The closest I've ever come to falling for a Gmail phishing attack
If the codes are time-based (TOTP), they are typically generated with a rolling window of 30 seconds (as you saw in Google Authenticator). The 30s rolling window is the recommended (and widely implemented) default value from the TOTP RFC [0].

It is common but not universal for sites to accept, at a given time, 1) the current U2F token, 2) the U2F token from the previous window, 3) the U2F token for the next window. This is done as a partial mitigation for potential clock skew issues on the client that's generating the TOTP codes (e.g. your phone). In practice this means every code is valid for 1m30s, although sites may customize this (with or without changing the window size, which is typically not done because that parameter must be consistent system-wide).

> If I wait till the last few seconds before using the code, does that make me any safer?

Maybe, but this is not practicable security advice. The latency of a MITM attack on a 2-factor TOTP login depends on the attack infrastructure and design, but can easily be made to be on the order of tens or hundreds or milliseconds. Reducing the window seems like it might help your security, but it can never be perfect and there is a direct tradeoff with usability because users need time to look up the codes on one device and enter them on another.

Folks often say "enable 2FA" in response to news of new and sophisticated phishing attack campaigns, but it's critical to note that most commonly deployed 2FA (TOTP, HOTP, SMS) is trivially phish-able. 2FA is not an automatic defense against phishing, although some newer designs achieve this and were created specifically with this goal in mind: U2F is a good example.

[0]: https://tools.ietf.org/html/rfc6238

garrettr_··on Open source collaboration across agencies to improve HTTPS deployment
pshtt (the HTTPS scanning tool) also powers the results for Freedom of the Press Foundation's recently launched Secure The News project: https://securethe.news. (Full disclosure: I work for FPF, and worked on Secure the News).

It's a promising project, and could use more contributors if anyone here is interested: https://github.com/dhs-ncats/pshtt/issues for ideas!

garrettr_··on The State of Linux Security
True, although sometimes it's good to deliver signed updates over a secure connection for defense-in-depth - for example, to mitigate vulnerabilities like the recent CVE-2016-1252.
garrettr_··on Ask HN: Why block Tor?
> It seems to have been untouched since, and no sign of an actual solution...

They're working on it! There will be a talk about this about Real World Crypto 2017 in January, see "Solving the Cloudflare CAPTCHA" on the RWC program: http://www.realworldcrypto.com/rwc2017/program.

garrettr_··on Filmmakers Ask Nikon and Canon to Sell Encrypted Cameras
> Too slow. RSA encryption is very expensive.

So use a public-key algorithm that is designed to be faster, less expensive, and use smaller keys -- e.g. NaCl's crypto_box, which uses Curve25519 under the hood: https://nacl.cr.yp.to/box.html.

> Also, RSA keys are enormous.

We're talking about devices that have as a primary goal the storage of lots of high-resolution media (photographs and video). I think you could find a couple extra KB to spare for an RSA public key... (although, again, there are better primitives than RSA that should be preferred).

garrettr_··on Worried About the Privacy of Your Messages? Download Signal
I'm probably just inviting myself to get trolled by replying to this, but this comment is just ridiculously wrong on so many levels.

> The fact that the guy behind it is hyping it via the New York Times, a generalist publication, instead of validating the thing through professional cryptographers (which he isn't) and recognised privacy champions such as the EFF is very telling.

Cryptographer Matthew Green on Signal's crypto and code quality (it was called RedPhone/TextSecure at the time of this writing): https://blog.cryptographyengineering.com/2013/03/09/here-com...

Version 1.0 of EFF's Secure Messaging Scorecard gave Signal 7/7: https://www.eff.org/node/82654.

> The thing has not been properly validated or verified (for a start, because there is no design document to validate against, and no published goals to verify against)

Signal has been analyzed, with favorable results, by academic researchers at least twice:

- https://eprint.iacr.org/2014/904.pdf - https://eprint.iacr.org/2016/1013.pdf

> it uses an ad-hoc encryption scheme from a non-cryptographer

Moxie Marlinspike and Trevor Perrin probably wouldn't call themselves "cryptographers," but almost anybody in the field would agree that they are experts on applied cryptography.

garrettr_··on Cloudflare ReCAPTCHA De-Anonymizes Tor Users
> It does obscure the size

Encryption does not inherently obscure the size of plaintext. Protocols may choose to pad plaintext for various reasons, and both Tor (since Tor always sends fixed-width cells) and TLS (when it uses a block cipher mode) do so. However, the amount of padding is typically small and can hardly be said to "obscure" the size of a request - it is not a defense against traffic analysis.

garrettr_··on The Tor Project: Building the Next Generation of Onion Services
Right, and this answers the parent's question. Currently, the layout of the HSDir is deterministic and therefore predictable by anyone, which allows for a number of potential attacks. See "Non-Hidden Hidden Services Considered Harmful" for context [0].

In the context of using the distributed randomness protocol to randomize the DHT layout, if the protocol were somehow broken then the worst case outcome would be that the DHT layout would again be predictable, which is no worse than the status quo today.

Disclaimer: IIRC there are some proposals to use the distributed randomness protocol for other things besides randomizing the DHT; I cannot speak to how those proposals might be affected if the distributed randomness protocol is flawed.

[0]: https://conference.hitb.org/hitbsecconf2015ams/wp-content/up...

garrettr_··on The Tor Project: Building the Next Generation of Onion Services
If you want to donate towards the operation of "safe" exit/bridge nodes, consider donating to NoiseTor: http://noisetor.net/.
garrettr_··on Show HN: Task-Based Electron Web Browser
Key feature for me would be the ability to switch/manipulate tasks through the keyboard only. Nice PoC!
garrettr_··on Geolocation API removed from unsecured origins in Chrome 50
This comment seems to imply that you're using a transport layer security mechanism < TLS 1.0, i.e. SSLv2 or SSLv3. I strongly encourage you to upgrade to TLS 1.1 or newer.
garrettr_··on WhatsApp's Signal Protocol integration is now complete
I always liked "Axolotol" because axolotols are a type of salamander with the amazing ability to regenerate parts of their bodies (including their brains!), and the Axolotol protocol, like OTR, is "self-healing", meaning it's capable of recovering from a compromised session key (https://whispersystems.org/blog/advanced-ratcheting/).
garrettr_··on Attack of the Week: Apple iMessage
Just use WhatsApp :)
garrettr_··on Security Checklist
> Do you have an account recovery flow? Delete it immediately.

What about users who need to, you know, recover their account?

garrettr_··on Opera: Introducing native ad-blocking feature for faster browsing
Firefox's Tracking Protection is not the same as Do Not Track (which "tells websites to not track my preferences so they can gauge what ads to show"). DNT is simply an advisory header and it has no effect because very few websites honor it.

Firefox's built-in Tracking Protection uses Disconnect's blocklist to block content that tracks you, preventing the tracking from happening in the first place. As a side effect, it blocks some, but not all, online ads. The thought was that online advertising is still an integral part of the web's sustainability, and so blocking it entirely would be too much - but advertisements that nonconsensually track users are a privacy and security risk, and should be blocked.

Until we have a reasonable alternative to advertising for funding the web, I personally consider Firefox's Tracking Protection to be a reasonable middle ground that hopefully sends a strong signal to advertisers - online tracking is creepy, unwanted, and puts millions of people's privacy at risk.

garrettr_··on 1Password sends your password in clear text across the loopback interface
Well, unauthenticated DH ("simple DH without any long term secret") is trivially MITM-able, so it could only be useful if you adversary could read but not write to the channel, which I doubt is the case in this context.
garrettr_··on What You Need to Know about HTTP Public Key Pinning (HPKP)
If you control the sites, just modify their server configuration so they send the HPKP header.

If you don't control the sites, it is not a good idea to pin them "from the browser" as you suggest.

garrettr_··on MEGAChat now includes end-to-end encryption
Have you taken a look at Cyph (mentioned elsewhere in this thread)? Their app is also basically cryptocat, but they've taken the time to engineer an interesting solution [0] to the "Trust on Every Use" problem that secure web applications have.

Of course, you still have the problem of deploying a secure application within the attack surface minefield of a web browser, but that's a separate issue.

[0]: https://docs.google.com/document/d/1PGS50eZB9Ud7wVKmrc0HU_FD...

garrettr_··on Analysis and Exploitation of a Linux Kernel Vulnerability
Freedom of the Press Foundation (disclosure: I am an employee) ships grsecurity kernels for SecureDrop. You have to build them yourself, but it really isn't that hard to do. We're working on making this easier for everybody by publishing guides [0] to building your own grsecurity kernel, as well as developing an Ansible playbook to automate building hardened kernels [1].

This is all still a work in progress, but expect a blog post once what we have is more polished.

A relatively easy-to-follow blog post was recently published that guides you through building a grsecurity kernel for a Debian desktop installation: [2].

grsecurity was operating a service last year that would allow you to request custom built kernels for a small price, although I can't find it now so it may have been taken offline. This is an ideal solution, and is actually better than packaging the kernels in an distribution's repository, because some of grsecurity's security features are more effective when everybody is running a unique kernel (e.g. RANDSTRUCT).

Finally, the linux-hardening group is working on upstreaming select PaX features into the mainline kernel [3], including PAX_REFCOUNT, which is the protection that would've mitigated this particular vulnerability.

[0]: https://gist.github.com/ageis/a91f36ca99c252291a00 [1]: https://github.com/freedomofpress/grsec/ [2]: https://micahflee.com/2016/01/debian-grsecurity/ [3]: http://lwn.net/Articles/668876/

garrettr_··on Analysis and Exploitation of a Linux Kernel Vulnerability
This vulnerability is a great advertisement for grsecurity/PaX, which mitigates it at the source of the issue thanks to PAX_REFCOUNT.
garrettr_··on Yubico with new 4096-bit keys and gpg-agent for ssh authentication
Not really, especially in the context of RSA keys, because:

1. RSA is a slow algorithm and gets slower as you increase the key size.

2. Increasing the key size gets diminishing returns on the security margin. Given the performance and compatibility issues, the relatively minor improvement in security once you go beyond a certain key size is not worth it (you should switch to a better algorithm instead).

3. Anything over 4096 (possibly anything over 3072) is overkill anyway - if you could break a 4096-bit RSA key, you've probably found a fundamental weakness in RSA that means you should move to a different algorithm entirely.

garrettr_··on Yubico with new 4096-bit keys and gpg-agent for ssh authentication
Sure! There are a lot of ways you can do this. One is to use PIV mode, which exposes a PKCS#11 interface that can be used by OpenSSL. Yubico has some nice docs on using a Yubikey as an HSM to store CA keys: https://developers.yubico.com/yubico-piv-tool/Certificate_Au...

Note that (at least in the method described in that document), the Yubikey does not _generate_ the private key, it merely stores it securely. You need to generate it on a computer, which should preferably be a brand new laptop, airgapped, purchased from a physical store and not online (continue to layer defenses up to your desired level of paranoia).

garrettr_··on How Tor Works: Part One
If you use Tor, or want to support those that need it to communicate safely online, consider donating to (their first ever!) end-of-year fundraising drive: https://blog.torproject.org/blog/our-first-real-donations-ca...
garrettr_··on What Satoshi Did
> By ensuring that no person could obtain an advantage over others, and by ensuring that anyone could join without exclusion, Satoshi created the Nash equilibrium to permit normally byzantine parties to enter and share safely in the definition of a shared network of contested assets.

This is roughly true, although Nakamoto's original paper only proves this for the case where no single entity controls > 50% of the mining power in the network (weak incentive compatibility). Nakamoto argued it was also true for the case where a single entity controls > 50% of the mining power (strong incentive compatibility) but failed to prove this, instead providing a vague argument based on some difficult-to-prove assumptions.

For more information, including an interesting theoretical attack based on this idea, see http://www.jbonneau.com/doc/BFGKN14-bitcoin_bribery.pdf.

garrettr_··on Mozilla Will Stop Developing and Selling Firefox OS Smartphones
Agreed, my favorite thing about Firefox OS was always the "blank-slate" approach to writing apps for it, based on web technologies. Of course, that was good and bad - there was more room for experimentation, but you had to do more work to get the widgets and smooth animation that come for free from iPhone/Android SDK.
garrettr_··on Leading 'anti adblock' provider gets hacked- pushed malware to end users
Not really. Since you need to know the correct hash ahead of time, Subresource Integrity works best when you're requesting a well-known piece of static data from a 3rd-party server, e.g. jQuery version x.y from a CDN. For a site like Pagefair (or other sites that serve 3rd-party scripts, like Google Analytics), the benefit of the web platform is being able to serve _dynamic_ data. You get to upgrade your software quickly and easily, without the friction of obtaining the cooperation of your website partners (1st party sites that included Pagefair's scripts) or end users.

If you want to use Subresource Integrity to prevent this kind of a problem, you need to first devise a mechanism to communicate the correct expected hash from the 3rd party site to their 1st party customers in a trusted manner. This is non-trivial. It adds a lot of friction to Pagefair's software development and deployment processes (think about how you would implement A/B testing, for example). It's also not a guarantee - if your servers can be hacked, it's possible your "trusted hash communication mechanism" would be as well, unless you follow stringent security protocols (human confirmation for signing, offline keys, etc.) which would add even more friction.

Of course, you would need cooperation and involvement from your first-party customers for SRI to be effective in the first place, and I don't know how many of them would be thrilled to have to devote engineering resources to fixing potential security problems caused by their partners... sounds like a good reason to consider switching to a competitor.

garrettr_··on A Guide to Fast Page Loads
> b) increasing the probability of malicious injection

Subresource Integrity (SRI) [0] was designed to avoid this potential vulnerability. It's a brand-new browser feature (jus t landed in Chrome stable, is riding the trains to Mozilla stable now) but it's worth taking a look at. Github is already using it [1].

[0]: http://www.w3.org/TR/SRI/ [1]: http://githubengineering.com/subresource-integrity/

garrettr_··on Keybase's New Key Model
I didn't design this so I can't say for certain, but from reading their post there are a couple of benefits that NaCL confers over PGP for generating per-device keys.

The most important benefit is probably that NaCL keys are 256-bit keys based on ECC (specifically, Curve25519), which means these keys are stronger, faster, and actually more secure than the strongest keys commonly used in PGP (4096-bit RSA keys). Critically, they are much smaller and therefore easier to communicate between people/devices.

While their ideal workflow is to communicate keys by scanning QR codes, they currently need an alternative workflow to communicate keys between desktops (and will always need an alternative for users who can't scan QR codes for whatever reason). The "Paper keys" section of the blog post discusses this at length, and shows an example of a Paper Key:

"death punch correct staple battery horse clearly cherry picked words yeah moo car lisp"

They are probably generating this (Diceware-esque) string by splitting the 256-bit key into n-bit segments, using each n-bit segment as an index into an array of words, and then joining the words to form a "sentence" that encodes the value of the key.

14 words is already pretty unwieldy, as they acknowledge in the blog post. Imagine how bad it would be if you had to encode 4096 bits instead of just 256!

That was probably the most important motivation for Keybase to use them. Other motivations may have included:

* ECC is generally considered more future-proof than RSA

* NaCL is a small library and therefore is probably easier to incorporate into a variety of clients rather than the behemoth that is GPG/libgcrypt.

* NaCL is the new hotness, PGP is old and busted

garrettr_··on How much of your audience is fake?
From an ad network's point of view, maybe, but from a publisher's point of view, no. This is just another variation on click fraud, because fake people don't buy real goods.

If you actually read the article, the Heineken advertiser's response is:

> “It was like we’d been throwing our money to the mob,” Amram says. “As an advertiser we were paying for eyeballs and thought that we were buying views. But in the digital world, you’re just paying for the ad to be served, and there’s no guarantee who will see it, or whether a human will see it at all.”

garrettr_··on Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
The point is that it's using ECB mode with RSA, which indicates the developer has no real knowledge of crypto and is just blindly using pairs of "encrypt/decrypt" functions from Node's built-in crypto lib (which is essentially a thing wrapper around OpenSSL and thus joins its illustrious legacy of encouraging developers to make catastrophic cryptographic implementation mistakes).

In encryptMessage.js, the plaintext is split into chunks, and then chunks.forEach encrypts each chunk (via crypto.publicEncrypt) independently, and concatenates the chunks to form the ciphertext, aka ECB mode. You shouldn't use ECB mode with any cipher because it is not semantically secure. This is Crypto 101.

In addition, it's a bit wacky to use RSA encryption on your entire message because RSA operations are slow and you are limited to encrypting messages that are the length of your RSA key (well, minus the padding, which is how this developer arrived at the "split plaintext into 214 byte chunks" workaround).

A better solution (in every way) would be to use a "hybrid" encryption scheme, similar to TLS or GPG. To do this, you would:

1. Generate a random key for use with a symmetric cipher (e.g. AES-256) 2. Encrypt the plaintext with the random key, using a secure block mode (e.g. CBC, CTR) 3. Encrypt the random key with the RSA public key 4. Package those things together and share it on Github

Efficient and secure. Also totally unnecessary (you basically just reinvented a subset of GPG) but that's neither here nor there.

← PreviousPage 2 of 3Next →