Threads for l_zzie

1. 4

   pizzaiolo 6 years ago | link | on: bitwarden - OpenSource Password Manager

   I see all these fancy password managers and I think… why not simply use an encrypted text file with your passwords on it? Less code, fewer vulnerability vectors.

   1. 16

      gecko edited 6 years ago | link

      Actually, there are potentially more vulnerability vectors.

      1. On a number of platforms (Windows, OS X, Android, and Linux), any application can subscribe to the clipboard. So if you’re copying your login credentials, anything on your system that might be compromised can grab it.
      2. Along the same lines, the vectors for leaking an unencrypted text file are actually quite high. While all of the password managers I know of are vulnerable to various forms of scanning (except 1Password on Windows when operated on the secure desktop), the text file is likely to be unencrypted in full in scroll back history or something similar for quite some time. There are ways to avoid this, but they’re tricky and error-prone; you can look at the history of PGP secure notes for some background here on all the ways to mess things up.
      3. An encrypted text file can also be difficult to merge. While you may be able to automate the process to a degree, you are again put into a position where you have to run your decrypted password file through multiple tools, which again increases your attack surface. E.g., most naïve ways of doing this would at least temporarily store both versions of your file unencrypted on disk to feed to a merge tool.
      4. An encrypted text file also cannot store anything other than logins and passwords, which makes storing other forms of secure data hard. E.g., in 1Password, I track what login pages of sites I haven’t been to look like, and explicitly track the full login page URLs, so that I can catch myself if I somehow fall for the first part of a phishing attempt. You can obviously do that without a password manager, but you’re now reaching for something like a LibreOffice document, which expands your attack surface and increases complexity.
      5. Finally, most modern password managers provide several things beyond mere storage, including cryptographically secure password generation, service exploitation monitoring (e.g., WatchTower for 1Password), which lets you know when a site you use has had its passwords compromised, and more. It’s not that you cannot do these things yourself, but it requires a lot of effort (monitoring HaveIBeenPwned, hoping you know to use arc4random or an equivalent with proper distribution across your alphabet, etc.). Collectively, these can dramatically decrease your attack surface, by allowing you to respond more effectively and proactively to site compromises.

      If storing all your passwords in an encrypted text file works for you, that’s fine; more power to you. But I don’t think it’s accurate anymore to claim that going that route is more secure than alternatives.
   2. 8

      zigg 6 years ago | link

      For the same reason you don’t manually decrypt and paste in your ssh private key every time you log in to a host—convenience.

      A password manager can also do some checks that humans may miss or flub, like stopping the pasting of your Gmail password into a convincing phishing site.
   3. 4

      mpcsh 6 years ago | link

      You would like pass(1)

      1. 1

         1amzave 6 years ago | link

         That’s a bit presumptuous – I’m not pizzaiolo, but while I do personally employ (essentially) the encrypted-text-file method, I think “pass” is actually pretty grossly misdesigned.

         1. 1

            l_zzie 6 years ago | link

            I have some issues with pass too: namely, it leaks metadata like names, creation time, and change history, and it encrypts without authenticating. Is there anything else I should know about?

            1. 3

               1amzave 6 years ago | link

               There are little things like its somewhat oddball dependency list (tree? what?), but the metadata-in-the-clear aspect is definitely the major one for me (the gross misdesign I referred to).
   4. 2

      aerique 6 years ago | link

      That would be hard to use on a mobile phone I think.

      1. 0

         z3bra 6 years ago | link

         I think it is not that hard to write a GUI application able to decrypt GPG encoded files, or read stdout by making subsequent calls to pass.

         1. 4

            kivikakk 6 years ago | link

            This is getting pretty seriously far away from the implied simplicity of “simply use an encrypted text file”.
   5. 1

      C-Keen 6 years ago | link

      Depending on your use case, this might be the solution. I have written my own at http://pestilenz.org/~ckeen/blog/posts/pee.html

1. 8

   inactive-user 6 years ago | link | on: BearSSL

   I find the lack of dynamic allocation especially interesting. In what sort of situations would this be necessary?

   1. 5

      LeahNeukirchen 6 years ago | link

      Embedded systems?

      1. 1

         inactive-user 6 years ago | link

         As an example though, what sort of system requires SSL and does not allow dynamic allocation? Not questioning the purpose of the feature, just curious :)

         1. 5

            l_zzie edited 6 years ago | link

            It’s not about “not allowing dynamic allocation”.

            Statically allocating everything is more predictable, since you don’t have to worry about e.g. heap fragmentation. It reduces some amount of security issues, like failing to handle malloc errors, and use-after-frees, and double-frees. It makes it impossible (ish) to have memory leaks, which can also be security-relevant. It makes it easier to write thread-safe code.

            1. 1

               inactive-user 6 years ago | link

               Ahhh, that makes a lot of sense. Thank you!
         2. 2

            ac 6 years ago | link

            You don’t know how annoying it can be when a library uses something you don’t have in some corner you have backed yourself into. its easier to just be careful from the start.

            I can imagine needing to use amazon IOT with client certificates on some bare metal platform for example.
         3. 1

            bitemyapp 6 years ago | link

            for when you need your refridgerator to make purchases with a credit card

            self-stocking fridge
   2. 1

      SeanW 6 years ago | link

      He wrote this book: http://www.prometheusbrother.com/ Which is interesting. All SSL hackers have very varied interests.
   3. 1

      nickpsecurity 6 years ago | link

      On top of embedded, they can be designed to use fewer resources if it’s a fixed-allocation scheme or easier to analyze. In terms of analysis, you might be able to do timing analysis for covert channel mitigation, same analysis for real-time situations, static analysis with tools like Astree Analyzer to show absence of critical errors, or whole app analysis showing it follow your policies in every successful or failed state due to determinism. Always go for static designs when you can. If you can’t, then mix the two so at least portions can be exhaustively shown to be correct with extra eyeballs on the dynamic stuff. Similar to mixing pure and impure components in languages like Ocaml.
   4. 1

      vfoley 6 years ago | link

      Dumb CS question: if you restrict yourself to static allocation, are you Turing-complete?

      1. 2

         lmm 6 years ago | link

         Individual programs are generally not Turing-complete (what would that even mean?) - the question only makes sense for language implementations. (Admittedly any program that accepts input is in some sense a language implementation, but for something that just decrypts SSL not really).

         A Turing-complete language implementation necessarily needs access to unbounded storage. In a sense such storage has to be “dynamic”, but it could e.g. use the C stack and potentially recurse to arbitrary depth (which I believe would qualify as “static allocation only” in the casual sense; it would be limited by stack size but you can set an arbitrarily large stack at runtime). Or use a fixed amount of memory and a file/database/etc. for storage.
      2. 2

         cmm 6 years ago | link

         Unless you are statically allocating an infinite amount of memory, no

         1. 2

            l_zzie 6 years ago | link

            …but this is true whether or not you restrict yourself to static allocation. There’s always an upper bound on memory on physical systems.

            1. 3

               cmm 6 years ago | link

               What do physical systems have to do with this? The same principle applies to Turing machines, you can’t simulate an arbitrary TM using a predetermined (finite) subset of the tape.
      3. 1

         skade 6 years ago | link

         Stack machines with just one stack and no other storage are not turing complete. Turing completeness is not a requirement for certain algorithms, though and sometimes avoided, because non-turing completeness does allow for more interesting proofs about the program at hand (e.g. liveness).

         Turing-completeness is also interesting because it is not hard to reach, making some things accidentally turing complete, such as Magic - the gathering.