Re: [FD] end of useable crypto in browsers?
On Sat, Apr 9, 2016 at 2:34 AM, Árpád Magosányi wrote: > Browser developers are dropping support for X509 key generation. > Yes, have its problems. But window.crypto - which is meant to > replace it - have no way to save keys in the browser's keystore. Using X.509 client certificates with browsers has a *huge* problem: they don't follow the same-origin policy, and was not designed for this in mind. Without following SOP, browsers wind up doing a terrible thing: prompting the user to select which TLS client cert/key to use with a particular web site. This is bad for both UX and security/privacy: users must make a decision, and if they make the wrong one they end up leaking information about their key to a potential attacker. Newer technologies like FIDO U2F tie generated keys to an "AppID" (Yubico goes as far as to include the AppID in key derivation itself), i.e. an "origin". This not only improves the UX by never having to prompt the user which certificate to use, but has the effect of making such tokens "unphishable" because an attacker domain will always get different keys from any other (as opposed to doing a challenge-response auth system with a key shared across origins, where an attacker can trick you into exposing it, and effectively MitMing the challenge/response) The reality of is its many problems meant adoption was extremely low, so it's not surprising that browser vendors want to axe it. -- Tony Arcieri ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] Telegram authentication bypass
On Tue, Apr 29, 2014 at 1:26 AM, wrote: > Thus, in this case, the development of such malicious client is not out of > their security model and it is an actual design flaw. I'm no fan of Telegram, but this is silly. Can you point to any security software that can survive the "client is duped into installing malware" attack? -- Tony Arcieri ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] keybase.io
On Fri, Jun 20, 2014 at 1:22 PM, Rikairchy wrote: > Why would a website focused on providing security allow users to > upload their private keys? > They are willfully creating a less secure system in hopes of making it popular. Supporting private key upload completely changes the threat model, from the end-to-end system they are allegedly trying to supplement, to one that's no different from just using TLS and a central service. I hope it's clear to any security enthusiasts where their priorities lie. Security takes a backseat to popularity. That's the wrong set of priorities for secure software. -- Tony Arcieri ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] keybase.io
On Sat, Jun 21, 2014 at 1:37 PM, Robert Dannhauer < r.dannha...@googlemail.com> wrote: > The only question: Can this be trusted? Can we make sure they don't know > the passphrase? No, the passphrase is being entered into a web page loaded from their domain. Unless you audit the scripts every single time you load the page, they (or anyone with access to their servers, or anyone able to pull off an XSS attack) could easily inject a keylogger or other mechanism for recovering the password. -- Tony Arcieri ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] keybase.io
On Monday, June 23, 2014, Jonathan Care wrote: > > Projects like keybase.io, mailvelope, and so on > You namedrop these projects as if they're the same thing, but they're not. - Keybase.io is a web page, and last I looked, they weren't using CSP, which would help prevent XSS - Mailvelope (which I use, and like) is a browser plugin. So is Google End-to-End Web pages and browser plugins have different threat models. A web page is ephemeral and fleeting. Attackers can selectively inject attack payloads at different page load times. Browser plugins are versioned artifacts. They're installed and updated as granular, auditable units. Using browser plugins for crypto is much less objectionable than "just a web page" IMO. I've written a blog post about this, FWIW: http://tonyarcieri.com/whats-wrong-with-webcrypto -- Tony Arcieri ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] Critical bash vulnerability CVE-2014-6271
On Thu, Sep 25, 2014 at 8:55 AM, Michal Zalewski wrote: > In what way? It doesn't have a logo, so it's a bit better in my book. That's where you're wrong: https://pbs.twimg.com/media/ByVh24fCcAAy7mT.png -- Tony Arcieri ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
