Security   551238

« earlier    

Latacora | Careers
How We Hire
We don’t care about your resume, like, at all. We hire almost resume-blind (if you send us a resume, we’ll read it, but we’ll probably forget about it before we get on the phone).

We don’t believe in interviews. We’ll interview you, at the end of our process, but by the time we do we’ll be pretty sure we want to hire you.

Rather than your work history, educational background, Github pages, Twitter profile, or your ability to write code on a whiteboard, we’re interested in your aptitude and enthusiasm for the problems we work on. The way we figure that out is with work-sample tests.

We give our candidates a series of challenges, time-calibrated to take about the same amount of time as a reasonable startup interview loop. Our challenges are designed to be scored on an “objective” rubric.

Our Process, Step By Step
We’re going to get on a call, and tell you more than you want to know about the company and our hiring process. You’ll get a name and a voice and contact information that you can use for the rest of our hiring process.
We’ll prep you for challenges. For instance: everyone (regardless of role) get a basic software security test. We’ll try our best to make sure you’re ready for it; there are books we like for boning up on this stuff, and we’re happy to send them. We have a practice version of the challenge you can take your time with. We don’t want to surprise you; we want to see you in the best possible light.
You’ll do challenges. On your couch, or in the park, or whatever. We’ve calibrated each challenge to take a certain amount of time; we did that to respect your time, not to make you work against a clock. If you want to noodle on a challenge for awhile, you can; we do our best to make sure you don’t have to do that to qualify.
If there’s a good fit right now, our challenge-review robuts have ascertained that. We’ll ask you to come out and meet us in person; when we do that, you’ll know we’ve tech’ed you out and want to find a way to hire you, which we hope makes that last interview pretty laid back.
If all has gone well, we’ll get you an offer and figure out when you can start.

If you want to move quick, we can wrap this up inside of 2 weeks. If you want to take your time, you can do that too. We’re almost always hiring and don’t do ruthless recruiter things to speed candidates up or lock them in.
job  interview  security  talks  tips 
3 minutes ago by some_hren
Latacora - The PGP Problem
Cryptography engineers have been tearing their hair out over PGP’s deficiencies for (literally) decades. When other kinds of engineers get wind of this, they’re shocked. PGP is bad? Why do people keep telling me to use PGP? The answer is that they shouldn’t be telling you that, because PGP is bad and needs to go away.

There are, as you’re about to see, lots of problems with PGP. Fortunately, if you’re not morbidly curious, there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography. No competent crypto engineer would design a system that looked like PGP today, nor tolerate most of its defects in any other design. Serious cryptographers have largely given up on PGP and don’t spend much time publishing on it anymore (with a notable exception). Well-understood problems in PGP have gone unaddressed for over a decade because of this.

Two quick notes: first, we wrote this for engineers, not lawyers and activists. Second: “PGP” can mean a bunch of things, from the OpenPGP standard to its reference implementation in GnuPG. We use the term “PGP” to cover all of these things.
The Problems
Absurd Complexity
For reasons none of us here in the future understand, PGP has a packet-based structure. A PGP message (in a “.asc” file) is an archive of typed packets. There are at least 8 different ways of encoding the length of a packet, depending on whether you’re using “new” or “old” format packets. The “new format” packets have variable-length lengths, like BER (try to write a PGP implementation and you may wish for the sweet release of ASN.1). Packets can have subpackets. There are overlapping variants of some packets. The most recent keyserver attack happened because GnuPG accidentally went quadratic in parsing keys, which also follow this deranged format.

Swiss Army Knife Design
If you’re stranded in the woods and, I don’t know, need to repair your jean cuffs, it’s handy if your utility knife has a pair of scissors. But nobody who does serious work uses their multitool scissors regularly.

A Swiss Army knife does a bunch of things, all of them poorly. PGP does a mediocre job of signing things, a relatively poor job of encrypting them with passwords, and a pretty bad job of encrypting them with public keys. PGP is not an especially good way to securely transfer a file. It’s a clunky way to sign packages. It’s not great at protecting backups. It’s a downright dangerous way to converse in secure messages.

Mired In Backwards Compatibility
PGP predates modern cryptography; there are Hanson albums that have aged better. If you’re lucky, your local GnuPG defaults to 2048-bit RSA, the 64-bit-block CAST5 cipher in CFB, and the OpenPGP MDC checksum (about which more later). If you encrypt with a password rather than with a public key, the OpenPGP protocol specifies PGP’s S2K password KDF. These are, to put it gently, not the primitives a cryptography engineer would select for a modern system. We’ve learned a lot since Steve Urkel graced the airwaves during ABC’s TGIF: that you should authenticate your ciphertexts (and avoid CFB mode) would be an obvious example, but also that 64-bit block ciphers are bad, that we can do much better than RSA, that mixing compression and encryption is dangerous, and that KDFs should be both time- and memory-hard.

You can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both.

Obnoxious UX
We can’t say this any better than Ted Unangst:

There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again.

If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. You probably don’t suddenly smell burning toast. Now try doing that with PGP.

Long-Term Secrets
PGP begs users to keep a practically-forever root key tied to their identity. It does this by making keys annoying to generate and exchange, by encouraging “key signing parties”, and by creating a “web of trust” where keys depend on other keys.

Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key.

Incoherent Identity
PGP is an application. It’s a set of integrations with other applications. It’s a file format. It’s also a social network, and a subculture.

PGP pushes notion of a cryptographic identity. You generate a key, save it in your keyring, print its fingerprint on your business card, and publish it to a keyserver. You sign other people’s keys. They in turn may or may not rely on your signatures to verify other keys. Some people go out of their way to meet other PGP users in person to exchange keys and more securely attach themselves to this “web of trust”. Other people organize “key signing parties”. The image you’re conjuring in your head of that accurately explains how hard it is to PGP’s devotees to switch to newer stuff.

None of this identity goop works. Not the key signing web of trust, not the keyservers, not the parties. Ordinary people will trust anything that looks like a PGP key no matter where it came from – how could they not, when even an expert would have a hard time articulating how to evaluate a key? Experts don’t trust keys they haven’t exchanged personally. Everyone else relies on centralized authorities to distribute keys. PGP’s key distribution mechanisms are theater.

PGP supports ElGamal. PGP supports RSA. PGP supports the NIST P-Curves. PGP supports Brainpool. PGP supports Curve25519. PGP supports SHA-1. PGP supports SHA-2. PGP supports RIPEMD160. PGP supports IDEA. PGP supports 3DES. PGP supports CAST5. PGP supports AES. There is no way this is a complete list of what PGP supports.

If we’ve learned 3 important things about cryptography design in the last 20 years, at least 2 of them are that negotiation and compatibility are evil. The flaws in cryptosystems tend to appear in the joinery, not the lumber, and expansive crypto compatibility increases the amount of joinery. Modern protocols like TLS 1.3 are jettisoning backwards compatibility with things like RSA, not adding it. New systems support just a single suite of primitives, and a simple version number. If one of those primitives fails, you bump the version and chuck the old protocol all at once.

Janky Code
The de facto standard implementation of PGP is GnuPG. GnuPG is not carefully built. It’s a sprawling C-language codebase with duplicative functionality (write-ups of the most recent SKS key parsing denial of service noted that it has multiple key parsers, for instance) with a long track record of CVEs ranging from memory corruption to cryptographic side channels. It has at times been possible to strip authenticators off messages without GnuPG noticing. It’s been possible to feed it keys that don’t fingerprint properly without it noticing. The 2018 Efail vulnerability was a result of it releasing unauthenticated plaintext to callers. GnuPG is not good.
The Answers

Talking To People
Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger.

Modern secure messengers are purpose-built around messaging. They use privacy-preserving authentication handshakes, repudiable messages, cryptographic ratchets that rekey on every message exchange, and, of course, modern encryption primitives. Messengers are trivially easy to use and there’s no fussing over keys and subkeys. If you use Signal, you get even more than that: you get a system so paranoid about keeping private metadata off servers that it tunnels Giphy searches to avoid traffic analysis attacks, and until relatively recently didn’t even support user profiles.

Encrypting Email

Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.

If you needed another reason, read the Efail paper. The GnuPG community, which mishandled the Efail disclosure, talks this research down a lot, but it was accepted at Usenix Security (one of the top academic software security venues) and at Black Hat USA (the top industry software security venue), was one of the best cryptographic attacks of the last 5 years, and is a pretty devastating indictment of the PGP ecosystem. As you’ll see from the paper, S/MIME isn’t better.

Sending Files
Use Magic Wormhole. Wormhole clients use a one-time password-authenticated key exchange (PAKE) to encrypt files to recipients. It’s easy (for nerds, at least), secure, and fun: we haven’t introduced wormhole to anyone who didn’t start gleefully wormholing things immediately just like we did.

Encrypting Backups
Use Tarsnap. Colin can tell you all about how Tarsnap is optimized to protect backups. Or really, use any other encrypted backup tool that lots of other people use; they won’t be as good as Tarsnap but they’ll all do a better job than PGP will.

Need offline backups? Use encrypted disk images; they’re built into modern Windows, Linux, and macOS. Full disk encryption isn’t great, but it works fine for this use case, and it’s easier and safer than PGP.

Signing Packages… [more]
pgp  crypto  encryption  software  security  talks  tools 
11 minutes ago by some_hren
Patron Checkout | Patreon
Objective-See writes great tools for security professionals and end users for macOS. This is their patreon page where you can contribute to this fantastic suite of tools.
Objective-See  software  macos  security  infosec  privacy 
21 minutes ago by emory
Safely Including Data for JavaScript in a Django Template - Adam Johnson
Django templates are often used to pass data to JavaScript code. Unfortunately, if implemented incorrectly, this opens up the possibility of HTML injection, and thus XSS (Cross-Site Scripting) attacks.
Security  Django  JavaScript 
24 minutes ago by cnk
Latacora - Stop Using Encrypted Email
Email is unsafe and cannot be made safe. The tools we have today to encrypt email are badly flawed. Even if those flaws were fixed, email would remain unsafe. Its problems cannot plausibly be mitigated. Avoid encrypted email.

Technologists hate this argument. Few of them specialize in cryptography or privacy, but all of them are interested in it, and many of them tinker with encrypted email tools.

Most email encryption on the Internet is performative, done as a status signal or show of solidarity. Ordinary people don’t exchange email messages that any powerful adversary would bother to read, and for those people, encrypted email is LARP security. It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
Technologists are clever problem solvers and these arguments are catnip to software developers. Would it be possible to develop a version of Internet email that didn’t have some of these problems? One that supported some kind of back-and-forth messaging scheme that worked in the background to establish message keys? Sure. But that system wouldn’t be Internet email. It would, at best, be a new secure messaging system, tunneled through and incompatible with all mainstream uses of email, only asymptotically approaching the security of the serious secure messengers we have now.

What should people use instead?

Real secure messaging software. The standard and best answer here is Signal, but there are others, and if the question is “should I use encrypted email or should I use a secure messenger”, we’re agnostic to which one you use. Or you can do more elaborate things. Magic Wormhole will securely exchange documents between people. age will encrypt documents that can be sent through less secure systems. These tools are all harder to use and more fraught than secure messengers, but they’re better than encrypted email.
email  encryption  privacy  security  crypto  talks 
39 minutes ago by some_hren
Welcome — Magic-Wormhole
Get things from one computer to another, safely.
This package provides a library and a command-line tool named wormhole, which makes it possible to get arbitrary-sized files and directories (or short pieces of text) from one computer to another. The two endpoints are identified by using identical “wormhole codes”: in general, the sending machine generates and displays the code, which must then be typed into the receiving machine.
The codes are short and human-pronounceable, using a phonetically-distinct wordlist. The receiving side offers tab-completion on the codewords, so usually only a few characters must be typed. Wormhole codes are single-use and do not need to be memorized.
cryptography  encryption  security  file-transfer  application 
55 minutes ago by moftasa
CyberPeace Institute
"Through assistance, accountability, and advancement we enhance the stability of cyberspace. We support vulnerable communities, analyse attacks collaboratively, and advance responsible behavior. The Cyberpeace Institute decreases the harms of escalating cyber conflict to realize the promise of the digital era for people all over the world."
Internet  web  security  social  citizen  community  peace  cybercrime  violence 
2 hours ago by kmo

« earlier    

related tags

1password  2020  2fa  510  644  account  adtech  ai  america  android  anonymity  api  app  apple  application  architecture  archive  art  audit  authentication  authorization  automobile  autorecon  awareness  aws  bad-actor  badtech  bestpractice  bestpractices  beyondcorp  bookmarks_bar  borg  brexit  browser  buzzfeed  certificates  checker  citizen  cli  cloud  codesign  coding  community  computer  configuration  continuousdelivery  course  crony-corporatism  crypto  cryptography  ctf  cultural-marxism  cybercrime  data  decrypt  deep-linking  defence  developers  development  devops  directory  diy  django  docker  documentation  e2e  education  elasticsearch  email  employment-policy  encryption  enterprise  esx  eu  europe  exploits  fbi  fido  file-transfer  file  firefox  forum-posts  free  game  geo  gis  github  golang  google  guide  hacking  history  homelab  hosting  howto  http  iam  immigration  infosec  infrastructure  inoreader  installation  interesting  internet  interview  ios  iot  javascript  job  k12  kali  key  kubernetes  labour-economics  labs  learning  liberal-elite  liberal-fascism  library  linked-data  linux  location  mac  macos  mena  messaging  metadata  metasploit  mobile  netsec  network  networking  news  nmap  notarization  oauth  oauth2  objective-see  oikophobia  opensource  openwhispersystems  oscp  otf  owasp  ows  passphrase  password  passwordmanager  passwords  peace  penetration-testing  pgp  place  policy  privacy  programming  protection  protocol  proxy  python  raspberrypi  reddit  reference  retention  risk  russia  sandbox  saudi  saudiarabia  scanning  security  servers  share  shell  signal  sip  social  software  sparkle  specification  spying  ssh  ssl  sso  standard  surveillance  sysadmin  systemd  talks  technology  tips  toolkit  tools  training  trump  trustmodels  tutorial  twitter  type:cheatsheet  upload  usernameless  video  violence  vmware  vpn  walkthroughs  web  webauthn  webdev  whatsapp  wifi  windows  wireguard  xcode  yubikey 

Copy this bookmark: