Show HN: Portable Secret – How I store my secrets and communicate privately

"Do you think this cannot possibly be secure? Great, prove it. This secret contains the recovery key for a Bitcoin wallet. Crack it and take my money!" Love it.

• mprime1 · 1372 days ago

  The first few times I shared this with (security professional) colleagues and friends, they'd dismiss it right away "this can't possibly work", but it was because they _assumed_ it didn't work (too simple). Attaching a challenge made a big difference, they'd spend 5 minutes trying to crack it and, in the process, realize it is actually sound (despite the simplicity).

  • lcnPylGDnU4H9OF · 1372 days ago

    > despite the simplicity FWIW, it's a simple composition of complex things. Still really cool, thanks for the idea!

  • water-your-self · 1372 days ago

    Why would they dismiss this?

    • mprime1 · 1372 days ago

      Because it seems too simple to be secure. (People are busy, attention is scarce, etc)

    • browningstreet · 1372 days ago

      Feels like the default human response in a lot of situations...

  • woodruffw · 1372 days ago

    I think this is very cool, and from a cursory look you've made most of the right design choices (to the extent that the Web Crypto API allows). That being said, I think most security professionals (myself included!) aren't equipped to outright "crack" this kind of thing in just a few minutes, and most should know better than to think that their inability to do so implies soundness. With that in mind, here are some things I noticed (none of which represent an immediate break!) * You're using SHA-1 in your KDF. That's probably fine since PBKDF2 doesn't rely on the properties of SHA-1 that have been broken, but the Web Crypto API gives you better alternatives. You could switch it out for SHA2-256 here without any breakage to the rest of the scheme. * I'm not a JS expert, but I _think_ your encryption page might allow a confused user to reuse an IV[2]. Normally this wouldn't happen because the user would refresh or reload and trigger the `init` on page load, but it would probably be better to generate the IV on demand rather than having it wait in an HTML attribute. Again, very cool work! The fact that people can make these kinds of self-containing encrypted applications with Web APIs is a serious testament to how far the standards have progressed. [1]: https://github.com/mprimi/portable-secret/blob/3b22d2b42baf8... [2]: https://github.com/mprimi/portable-secret/blob/4de5e958fe6f8...

    • mprime1 · 1372 days ago

      Thank you. > most security professionals (myself included!) aren't equipped to outright "crack" this kind of thing in just a few minutes When I say 'crack' in this context, I mean review the scheme and point out any obvious flaws, like you just did! > SHA-1 -> SHA2-256 I should do this! > reuse an IV Indeed (there is a fine-print in the creator page that says "don't reuse across messages", but I should just regenerate proactively) Thank you very much for the great comment!

• ranting-moth · 1372 days ago

  Very creative and efficient use of $400 on PR/advertising!

  • tanseydavid · 1372 days ago

    What is your comment referring to? I must have missed something...

    • wnevets · 1372 days ago

      the bitcoin wallet is worth ~$400 [1] [1] https://mprimi.github.io/portable-secret/examples/bounty.htm...

  • mprime1 · 1372 days ago

    $400 or $0? I don't think of it as PR/Ad. It's a bounty. If you put in time to find a flaw, you deserve at least that much (and I'll give you more if you help me fix it).

    • irjustin · 1372 days ago

      Why can't it be both?

• vorpalhex · 1372 days ago

  This is a smart use of crypto too. The verifiable and public parts of crypto here are a benefit and not a con.

  • ivalm · 1372 days ago

    but you are not guaranteed that the decrypted key is valid.

    • ninkendo · 1372 days ago

      I hate that I’m saying this because I believe all of cryptocurrency to be a pyramid scheme, but… this is the perfect use case for a smart contract on ethereum… (Now I gotta go wash my hands after typing this.)

      • ivalm · 1372 days ago

        why would a smart contract help though? there needs to be proof that the encrypted key is valid, this would require zero knowledge proof but I'm not sure how you can do it for this use case.

        • ninkendo · 1372 days ago

          He could post a secret in the decrypted text on the page that, once submitted to the chain, fulfills the contract and transfers the ETH. I know very little about smart contracts but I thought this is what they’re good at… “if a value is posted with a sha512 hash that matches x, the contract is fulfilled”, and put the value on the page, encrypted, and ask hackers to decrypt it. It doesn’t necessarily prove that the encrypted key is valid, but it proves that the author put some money up on the chain at least. It could always be that the decrypted text doesn’t provide the key that fulfills the contract, but ultimately that isn’t a solvable problem. You can’t prove a claim about some encrypted text without someone having the ability to decrypt it.

          • ivalm · 1372 days ago

            But then you don’t need to have a smart contract, simply posting public key of the wallet is enough (to verify the content of the wallet). The contract at most provides an escrow, but even that isn’t really the case since presumably the originator has the key to pull the money (since he knows the secret key). Proving that an encrypted text has the private key is possible for some encryption schemes through zero knowledge proofs, but I guess not in this case in particular.

  • isitthough42 · 1372 days ago

    If someone tells you: This secret image contains a Bitcoin wallet recovery key If you can crack the secret, the funds are yours! You can check the status of the wallet here: https://www.blockchain.com/explorer/addresses/btc/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa Now here's the secret: 0002146273a3774b3828effff3382000someGarbageSecretThatsActuallyIs{https://youtu.be/eBGIQ7ZuuiU}EnctyptedUsingARandom4096BitStringAsPassword Which "verifiable and public" part helped? - Anyone can point to a random link on blockchain.com - the encrypted secret can contain anything

    • jimmydorry · 1372 days ago

      They didn't do it here, but you can sign a message that includes a checksum of the application with the private key of that address. The signed message can be proved using just the public key that they have linked to.

• europeanguy · 1372 days ago

  What happened to the "don't roll your own crypto" that HN loves?

  • bobleeswagger · 1372 days ago

    I can't be the only one who thinks this wallet will be emptied before 2023. Security by obscurity is real, there's nothing secret about defining the problem space in which your attackers can search.

    • mprime1 · 1372 days ago

      I'd be happy to see the wallet emptied. This is what the bounty is for. I just hope whoever cracks it lets me know how they did it and how hard it was. This is what a bounty is, no?

      • bobleeswagger · 1372 days ago

        $400 is nothing, put your life savings into this system if you trust it so much. It's a cute marketing gimmick, that's about it.

  • ncallaway · 1372 days ago

    They didn’t roll their own crypto? They used the web crypto API provided by the web browser.

  • skrebbel · 1372 days ago

    this doesn't, it uses the browser's builtin Web Cryptography API. if using a crypto algorithm also counts as "rolling your own crypto" then what's left? just don't encrypt anything, ever, because HN says we shouldn't roll our own?

    • europeanguy · 1372 days ago

      Yes, using a crypto algorithm also counts as rolling your own crypto. You're putting together crypto libs that others wrote. Most crypto vulnerabilities come from glueing together solid crypto implementations. The glueing has to be solid too. Just "using" a crypto algorithm sounds like a recipe for a vulnerability. I'm not a crypto expert, I'm just telling you what I've been reading on HN for the past few years.

      • bobkazamakis · 1372 days ago

        re-using primitives is on a completely different level from creating your own cipher.

      • maqp · 1372 days ago

        You're not completely wrong in that it's still possible to f up, even when using misuse resistant primitives. The difference is, you're sort-of allowed to f up if it's an intelligent mistake that teaches the creators of misuse resistant libraries a thing or two about where they went wrong. If OTOH you're clearly just yoloing it, introducing your pseudo-math BS into the mix, or intentionally deviating from best practices or breaking it, then it's on you.

• quickthrower2 · 1372 days ago

  Notice they have also given clues to what the password words are. So with brute force, maybe spending a good portion of the bounty on cloud resources, you might crack it that way :-)

• cakoose · 1372 days ago

  Offering a bounty like this has value, but probably only for finding shallow bugs. Thoroughly evaluating security/cryptography takes deep expertise and a lot of time. You're not going to elicit that without more money, impact/fame, or technical excellence. - Money: The original bounty was $400. An expert can probably earn $400 an hour just to investigate something, without needing to completely break it. - Impact/fame: Barely anyone uses this project. There are tons of other tools and services that are more widely used. - Technical excellence: There's no evidence of anything clever or interesting. For example, researchers around the world spend tons of effort analyzing the algorithms in the various NIST cryptography competitions. There's significant impact/fame and clear evidence of technical excellence. But if some rando offers a $10k bounty for their encryption algorithm, it's not going to get the required level of scrutiny. Plus, the bounty is just for the encryption mechanism. With security, it's usually the other moving parts that cause issues, especially in how they interact with human behavior. Phishing works without needing to break TLS, DKIM/SPF, browser sandboxing, etc. (I read an article ~5-10 years ago by a security/crypto researcher that said basically this, but sadly I can't find it anymore.) I still think it's great when people build things like this and when they offer any kind of bounty. I just worry that the presence of an unclaimed bounty might mislead people into overestimating the level of security.

  • mprime1 · 1371 days ago

    FWIW, I (author) agree wholeheartedly with everything you say. I'm just sharing a little hack I came up with. I hope some people add it to their toolchain (not my specific implementation, the idea in general). And offering a bounty seemed like a fun things to do, which may also catch some shallow bugs, reward the hunter, and shame me publicly :-)

I built a similar tool after Firefox send got killed. It was only for transient messages (e.g. sending secrets to someone else or an other device). I don’t know that I love the idea of these being long-lived, as I’m not sure I trust my password abilities.

It would be awesome if this could be code-golfed into a small enough package to fit in a QR code.

• mprime1 · 1372 days ago

  Do you mind expanding? Specifically, what do you mean by de-golfed (I'm only vaguely aware of what 'kids' mean by code-golf these days, and I'm kinda lost on de-golfing). What would you like to fit into a QR code? A PortableSecret (e.g. html file)?

  • nicce · 1372 days ago

    Not the original commenter, but if the whole HTML could be included, it would be nice. It is defenitely possible until certain data limits. However, you would need certain app to use it, since by default QR readers probably can’t benefit from it so that it actually increases the usability. File should be extracted and then opened with browser from correct path.

  • Phemist · 1372 days ago

    Code golfing is the act of finding ever and ever smaller, but functionally equivalent, expressions of a specific piece of code. Usually involves a lot of tricks specific to the language the golfing is done in. So yes, it would contain the PortableSecret minimized to such an extent that the whole thing fits in a QR-code (which has a practical upperlimit of a few KB?)

    • mprime1 · 1372 days ago

      Gotcha. Thank you. IDK about including a full HTML into a QR code (how would you even open it? Wouldn't a reader get confused expecting a URL or plain string?) But... You can publish portable secrets on your website (just make sure they aren't advertised/linked/crawled) and then create a QR code of the (secret-by-obscurity) URL.

      • captainredbeard · 1372 days ago

        Use a data URL and use base64 variant of the resource

  • c22 · 1372 days ago

    Like sibling comment elucidates, code-golfing is just using tricks to get the size of a program down without impacting its functionality. This could be as simple as using single-character variable names or something more complicated like including a decompressor that expands some packed code before execution. If you got the decryption code plus the payload small enough you could theoretically put the whole thing into a data URL (a URL that doesn't link to a remote resource, but contains all the data needed to display a web page). This data url could theoretically then be encoded into QR and accessed entirely locally on anyone's smart device.

    • aporetics · 1372 days ago

      This used to be called munging

      • TedDoesntTalk · 1372 days ago

        It’s called minification in the JavaScript ecosystem.

        • ricardobeat · 1372 days ago

          Minification may, or may not, involve munging, for example shortening `const foobar = 1;` into `var f = 1;`. This is not always a safe operation, and in some cases you want to disable munging when minifying your code so that you have meaningful component / function names in your stack traces even without sourcemaps.

    • mprime1 · 1372 days ago

      > If you got the decryption code plus the payload small enough you could theoretically put the whole thing into a data URL (a URL that doesn't link to a remote resource, but contains all the data needed to display a web page) This is how the 'secret creator' page works :-)

  • ignoramous · 1372 days ago

    Not just QR code, may be small enough secrets fit in a URL (2KB I think is the limit)! See also the now defunct sharelock.io by Auth0: https://news.ycombinator.com/item?id=9109924 For creating and later validating magic-links (using Web APIs), I encode the IV, Salt, Cipher all in the URL as a single base64 token: https://github.com/celzero/otp/blob/cddaaa03f12f765fa8da9178... (Btw, reading through your code makes me wonder if I should pad the plaintext to match blocksize despite https://archive.is/NX7Y2 )?

    • mprime1 · 1372 days ago

      You are saying padding might be superfluous because of AES-GCM, correct? (I was using AES-CBC before, that's why the padding is there)

neat tool. I would encrypt the payload type and extension tho >Some browsers disable window.crypto on local files and non-TLS servers which ones do that?

• mprime1 · 1372 days ago

  Brave and Safari that I know of. i.e. if you run the creator with a simple HTTP server on localhost:8080 it'll block the fetch to localhost:8080/foo

  • throwaway0x7E6 · 1372 days ago

    for local files as well?

    • mprime1 · 1372 days ago

      Yes. If that wasn't the case, then "HTML virus" would be a thing: I send you an HTML file and, if you open it, it read files from your hard drive and uploads them to my server.

      • jefftk · 1372 days ago

        The problem with your scenario is the reading the local files without permission, not the use of the crypto API.

        • mprime1 · 1372 days ago

          You are right, I'm conflating 2 issues. I'm pretty sure Brave was blocking window.crypto but can't remember if it was on a file or over plain HTTP

          • jefftk · 1372 days ago

            Blocking crypto on http:// is to spec (aside from localhost) and all the browsers do that. Blocking crypto on file:// is not to spec, and testing above ( https://news.ycombinator.com/item?id=34084526 ) none of the browsers do that.

            • mprime1 · 1372 days ago

              It's been a while and I don't remember the details. All I remember is that I was developing the secret 'creator' code using Brave (my default unsecured browser) and at some point I had to switch to Safari (which I normally save for trusted websites only). It's possible it was a red herring, and I switched browser but the problem was something else I did at the same time.

      • throwaway0x7E6 · 1372 days ago

        I should have clarified - I mean I was wondering if any browsers block fetch to remote URLs from local files I do vaguely recall encountering some problem I didn't expect when I was making a tool contained in a local html file, but I dont remember which browser I was using at the time

• jefftk · 1372 days ago

  It is documented [1] as only being available in secure contexts, which is normally https:// but does include file:// urls. Testing now, it works for me in Chrome, Safari, Brave, and Firefox. If you put: <script> window.crypto.subtle.generateKey( {name: "ECDSA", namedCurve: "P-256"}, false, ["sign", "verify"]) .then(function(key){alert(key.publicKey)}) </script> in a local HTML file and visit it in your browser, all four browsers alert with "[object CryptoKey]". [1] https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subt... [2] https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

Please add this: decrypt also on pressing key "Enter". Thank you!

• mprime1 · 1372 days ago

  If it's any consolation, it's on the TODO list (not a web/JS developer if it wasn't clear from the crappy CSS)

So, the next step would be to have this in front of a S3 upload dropzone that generates a public link which self-expires after a few days? As in, here's a link to a file, you know the password, it'll self-destruct (disappear) in 24 hours.

• mprime1 · 1372 days ago

  Sounds cool! All I wanted to show with this project is the concept of self-contained, self-extracting, super-portable secrets.

• edwnj · 1372 days ago

  I had the exact same idea years ago when I was working on a secrets manager (hobby project).. Self Destruction, Unique link + password makes it pretty secure. With the exception of Internal sabotage, I don't see any other issue.

This is really cool! The "lost thumbdrive" comment makes me wonder if a browser from 20 years (or more) in the future will still have enough legacy functionality to decrypt these payloads.

• ptspts · 1372 days ago

  Even if not, it's affordable to hire a programmer for a few hours to migrate the code to the newer API.

  • withinboredom · 1372 days ago

    I doubt that would work. You can’t decrypt things encrypted 20 years ago on modern API’s because those algorithms are known to be insecure. You’d have to probably rewrite it from scratch or install an old version of the browser. So it’s probably best to keep a windows version of the browser since that’s currently the only OS that can run software from 20 years ago, so hopefully they’ll still be able to do that 20 years from now.

    • wizzwizz4 · 1372 days ago

      The cryptography is insecure. The code often is secure – it's just doing an insecure thing. In this example, the encrypted data is (perhaps) insecure, because the cryptography algorithm has known exploits. Consider a magic unpickable door lock that automatically unlocks itself at midnight. The lock has no security vulnerabilities (it's doing exactly what it's supposed to, and there's no way to subvert it), but your house probably does.

      • withinboredom · 1372 days ago

        I’m not sure if anything you said makes any sense in the context of my comment, are you sure you’re replying to me?

        • wizzwizz4 · 1371 days ago

          I assumed you meant something slightly different to what you wrote, because you wrote: > You can’t decrypt things encrypted 20 years ago on modern API’s because those algorithms are known to be insecure. Python's standard library, C's standard library, and Win32's CryptoAPI all beg to differ. The specific algorithms used by Crypto.subtle (Rijndael, Rivest–Shamir–Adleman) are over 20 years old, already, so even that's a counterexample. > So it’s probably best to keep a windows version of the browser since that’s currently the only OS that can run software from 20 years ago, so hopefully they’ll still be able to do that 20 years from now. Most operating systems can run software from 20 years ago. I'm currently running a 35-year-old piece of software on the latest version of an OS that isn't Windows. (I'm not aware of modern Windows being able to do that, actually; not since NTVDM got removed.) Does this address your comment better?

          • withinboredom · 1371 days ago

            > Does this address your comment better? Much! I'd say that there is always a counter-example. However, even RSA was generally recommended as "insecure" because people can't bother to do any research into the correct values of the parameters. The algorithm itself is secure, but most libraries didn't have sane/secure defaults until like 10ish years ago. That was the point I was trying to make, you're making a bet that what we know today will still be true 20 years from now. The algorithms you mentioned are symmetric, IIRC, and basically any symmetric algorithm is secure as long as you have a one-time-pad or don't know any of the cleartext. That is, until someone finds a flaw with it. I remember working on my first 'ciphersaber[1]' when it was discovered it was insecure. > Most operating systems can run software from 20 years ago. I was mostly referring to main-stream OS's. Linux and OSX, for example, cannot run software compiled 20 years ago (I'd love to be proven wrong, but my experience hasn't been so great!). On my modern Windows 11 PC, I can still run my first game engine demo, written and compiled in 1998 (I've since lost the source code). Or via WINE on my Linux PC, probably. I'm sure there are niche cases out there, but the vast majority of people don't have access to those systems and OS's, while anyone can (currently) run a basic version of Windows for free. [1]: http://ciphersaber.gurus.org/

            • wizzwizz4 · 1369 days ago

              > Linux and OSX, for example, cannot run software compiled 20 years ago (I'd love to be proven wrong, but my experience hasn't been so great!). Just get the copy of libc it was compiled for (and any other libraries), and add them to LD_LIBRARY_PATH before running the program. Linux's ABI is stable, so this should work fine. (It's always worked for me – though I haven't tried terribly much software, I'll admit.) I don't know about macOS; iOS has compatibility problems, but Android basically doesn't.

This is password protected, so then an attacker must crack the password. The author exchanges the password over a phone call, which requires the password to be relatively weak, meaning the password is probably crackable. Exchanging the password via a second channel that the other user can copy and paste a more difficult password from to decyrpt the document might be more secure. The password may be more exposed, but an attacker would have to compromise both channels. Basically use two messaging platforms (one of which could be email) ideally where at least one channel is sent encrypted. For example if the other party is using their mobile phone to view the payload they should have a messaging app to copy and paste from that is at least encrypted in transit if not e2e.

• mprime1 · 1372 days ago

  This is not meant as a solution. It's a demo of a self-contained, self-extracting, portable encrypted file. That said, the password strength and the strength of the side-channel to transmit it depend on your use case. If we were friends for example, I may not need to send you a password at all. I could just add some secret questions we both know in the hint. Or, at the opposite side of the spectrum, I could send you a secret as email attachment and *include the password in the email itself*. This adds zero security in certain scenarios, but for example it keeps Google bots out of your private correspondence. Which is all I want sometimes.

  • mikedelago · 1372 days ago

    the author even says that this is more for convenience rather than impenetrable security: > I created Portable Secret to securely exchange documents via email with my mother, who can’t be expected to learn PGP, age, or similar.

  • tharkun__ · 1372 days ago

    Challenge: make it possible to use something like Diffie Hellman[0] to exchange a key securely even over an unsecure channel but where they resulting key is actually the password to type in and "reads" like https://xkcd.com/936/ i.e. something my grandma could type in. Without reducing the key space too much to be insecure ;) [0] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...

• bryanlarsen · 1372 days ago

  The author recommends the use of XKCD correct-horse-battery-staple style passwords (aka diceware), which have a high ratio of entropy to ease of transmission effort. In other words they're relatively easy to exchange over a phone call but still secure.

  • mprime1 · 1372 days ago

    And you can compose them from "pre shared" secrets. For example, the password hint for a secret I send to my sister: - The name of our neighbors cat - The name of your first boyfriend who scratched dad's car - Mom's nickname for aunt Ilda Concatenate those three with a dot. And voila, a pretty secure password without need of a side channel. (just made this up, I don't have a sister...)

    • tash9 · 1372 days ago

      Whatever, now we know your password is "Miffy.Biffy.Boffy"

    • zikduruqe · 1372 days ago

      Or just put it up on the kitchen wall... "Live well, Laugh Often, Love Much"

• passwordoops · 1372 days ago

  It does not mean the password needs to be weak at all. Make it a full sentence with punctuation, like: "Don't you hate passwords that need a number and symbol?" Easy enough to transmit over the phone and definitely more difficult than the ubiquitous "Password1!" that most people I know end up using to meet password "security" requirements. Also, phone exchange can be preferable for many people who are less tech comfortable

• OkayPhysicist · 1372 days ago

  Passwords being transmitted over a voice call does not equate to a weak password. You can very easily communicate 4-6 English words outside the 10,000 most common to produce a password with 49-83 bits of entropy. And most people will have just as easy a time remembering 5 words as 5 alphanumerics, if not easier.

• jmspring · 1372 days ago

  There is nothing requiring the password to be “weak”. It can be a strong password generated with a random number/strong password generator. Sharing a string of characters or a “weak phrase” is no different if reading it to the person.

• jononomo · 1372 days ago

  "The author exchanges the password over a phone call, which requires the password to be relatively weak" -- where did you get this idea from???

• jononomo · 1372 days ago

  Over the phone I could tell someone: "the password is the first 28 words of Psalm 23 from the King James Version." Would that be a weak password?

  • falcolas · 1372 days ago

    Funny enough, the Bible's well enough indexed, and in small enough chunks, that you could just send someone: Psalms23:2 and have a 14 word passphrase.

  • booi · 1372 days ago

    Yes because the paraphrase already exists in plain text somewhere public

    • jononomo · 1365 days ago

      28 words would be about 200 characters, though, and I don't think simply existing somewhere in plaintext is enough -- what if I said it is the first 28,000 words of the Latin Bible -- would you still consider that a weak password because it exists in plain text somewhere?

• aidenn0 · 1372 days ago

  I took a list of "2000 most common English words" used metaphopne to eliminate words that sound similar to other words on the list, and reduced it to a power of 2. I ended up with 512 words that are probably in all fluent English speakers vocabularies so can easily be read over the phone. It's 9 bits per word, so 7 words is 63 bits of entropy which means it's (on average) 2^62 times more computational work to brute-force than it is do decrypt. That's a pretty good margin to have. If they were using a stupid hash like, say, MD5 the time to brute force that would still be months on a GPU, but they are using PBKDF2/SHA-1 which is significantly more work.

Nice idea but it seems not resilient against a rainbow attack.

• lolinder · 1372 days ago

  There's a ~$400 bounty for anyone who'd like to try.

  • mkl95 · 1372 days ago

    Hold my beer for a few billion years while I crack it.

    • huehehue · 1372 days ago

      The bounty password looks like 2 names, a type of flower, and a two word object. That significantly reduces the search space. Though, it's likely at least one of those words are non-standard or wouldn't be found in any wordlist.

      • mprime1 · 1372 days ago

        All words appear in some wordlist. This is the kind of password I use to protect my actual secrets. So if someone is able to crack it, I'd like to know. The bounty is for a 'realistic' use case.

        • TedDoesntTalk · 1372 days ago

          If you want to avoid wordlist vulnerabilities, try this: Choose a lyric from a favorite song. Concatenate the first letter of each word in the lyric. Example: “Rock the Casbah Sharif don't like it” Becomes: rtcsdli Add capitalization or numbers/special characters according to your own pref. For example, maybe your decide to alternate lower and upper case and always end with a bang: rTcSdLi! Although you have to use the same capitalization rules for all passwords if you have any hope of remembering them.

          • bryanlarsen · 1372 days ago

            That is security by obscurity. If somebody knows your method, they can scrape the lyrics for all popular songs, narrow your password down to a few million possible passwords and just try them all.

            • TedDoesntTalk · 1372 days ago

              > to a few million possible passwords The combinations are easily in the trillions, likely much much more. Read the algorithm. An algorithm for password generation is not security by obscurity.

              • bryanlarsen · 1372 days ago

                10s of thousands of popular songs, dozens of lines per song. > Although you have to use the same capitalization rules for all passwords if you have any hope of remembering them. So no additional combinations from that. Your algorithm is simple and common enough that it's possible that an attacker can figure it out from a single leaked password. With one leaked password they've compromised all of your passwords to anything they have the capability of trying a few million passwords on.

                • TedDoesntTalk · 1372 days ago

                  You wrote Pooh songs. Not me. There are millions of songs with lyrics. Billions of lines of lyrics. Trillions of combinations that include upper and lower case. Good luck.

          • fitzroy · 1372 days ago

            If your favorite song is by Pearl Jam you get an extra layer of security: https://www.youtube.com/watch?v=xLd22ha_-VU

    • quickthrower2 · 1372 days ago

      I bet 1000 years will be enough as tech and math progresses. Or 24h, flight tickets, and a wrench.

• beardog · 1372 days ago

  It looks like it uses a randomly generated unique 128bit salt from crypto.getRandomValues, can you explain what it is doing wrong to be rainbow attack resistant? https://github.com/mprimi/portable-secret/blob/main/creator/...

• dariusj18 · 1372 days ago

  Yeah, plus they even give hints to the password complexity, so unless that is a red herring, this should be pretty simple to crack, if not CPU consuming. Just combine https://github.com/mejdoubi/rainbow-table and their algorithm together. It would probably take me a few hours to put together, but for someone who is very familiar with cryptography, it would be minimal work.

  • falcolas · 1372 days ago

    Sounds like a quick $400 for you then. :)

  • mprime1 · 1372 days ago

    I'm willing to sweeten the deal. What amount of money would make you actually try to crack it?

  • pertique · 1372 days ago

    I think the author of that repo misunderstands what a rainbow table is. I only quickly skimmed the code, but it doesn't seem to do anything related to rainbow tables. On top of that, a rainbow table (if that is what you're looking to use) would not help here. The password is both very long and salted.

    • dariusj18 · 1371 days ago

      The repo was just a quick example of how one would use a rainbow table to crack the password. Yes, the fact that it only generates a simple rainbow table means that it isn't the holy grail to the exercise, but the idea of a rainbow table is that someones out there have already been running and generating a rainbow table for many years.

Works on mobile. It is amazing what all the browser APIs enable as a target platform of its own. And the portability that the (probably-disgusting amount of lines of) code provides.

Just was playing with this more. Visiting the secret's page from the "recently closed" or "history" views of Brave/Chrome leaves the password in text entry box. Edge doesn't do it. Probably there's some easy fix for it, I'd guess, but I'm not really a web dev.

• mprime1 · 1372 days ago

  Interesting, thanks for saying something. I'm also not a web dev, but I think I can manage to clear out the password once the secret is decrypted successfully.

  • tingletech · 1372 days ago

    or use <input type="password"> ? But then one can't read the password as one types.

    • withinboredom · 1372 days ago

      Change it to text on focus, password on blur. It will still be in the history though… clearing it on submit makes the most sense.

  • chadlavi · 1372 days ago

    changing the type of the input from text to password will help. also the required attribute does nothing in html if the input is not part of a form.

This is incredibly cool! Nice demo of a modern browser API I was not aware of, and it's actually useful. I can imagine using this to email confidential PDFs and other small deliverables for clients.

• mprime1 · 1372 days ago

  Exactly one of the reasons I came up with this. One way to see this is "like encrypted PDF, but for any kind of file".

I can confirm that the password for the bitcoin wallet is not banana.

• newcool1230 · 1372 days ago

  Have you tried banana banana?

Why not use any of a bunch of other services? Surely you can't think your threat model allows for this but not 1pass?

• mprime1 · 1372 days ago

  It's not a service. It's a simple hack and I use it for 3-4 use cases for which no service exists. Among other things: - It works offline - My mom can use it - It works on any device (even a borrowed one or a newly formatted one) - It can save me if *all* my devices get stolen - It can save me if I'm stranded in a foreign country without any document or trusted devices, - Etc.

  • SpeedilyDamage · 1372 days ago

    I get that, but why not use a service, instead of this manual process? 1pass literally can solve every single one of these problems.

    • gregw2 · 1372 days ago

      Not speaking for the poster, I would rather trust a mainstream browser's crypto API than 1pass.

      • SpeedilyDamage · 1372 days ago

        That’s idiotic…

Cyphers, the algorithms used to encrypt the secret file, become obsolete over time. We still need to solve for obsolescence. You can encrypt a file today using a cypher that will eventually be removed from all browsers, desktops, and phones.

• theamk · 1372 days ago

  I guess this is a downside of the browsers. If I want to run ancient app (MS-DOS or even ZX Spectrum), there are plenty of well supported modern emulators. But a 5 year browser with feature removed for security reasons like Flash? That's much harder.

• mprime1 · 1372 days ago

  2 sides of obsolescence: - Too old, no software can decrypt it: not worried about this. These are NIST-standard algorithms, there built-in in most programming languages, they'll be around for a while - Too old, trivial to crack: this is a bit more concerning to me. It's possible that some entities around the world can already crack this encryption in minutes/hours days Regarding the second, I'm already working on an Elliptic Curve version of this.

  • Kon-Peki · 1372 days ago

    Well, your cipher text could decrypt to a non-published URL that has some cipher text which decrypts to another non-published URL (as many layers of indirection that you need), with the final non-published URL containing the actual cipher text you wanted to decrypt. You can check server logs to see if those URLs are ever hit. And if you ever need to, you can abandon the original link after changing what those non-published URLs point to (something "fun", like a rickroll perhaps). In fact, how about using the Wayback Machine to store a bunch of versions of the static page, each containing different versions of the cipher text. Only you know which date range contains the proper cipher text!

    • mprime1 · 1372 days ago

      Genius. As the old adage says 'any problem can be resolved by adding one more layer of indirection'.

• falcolas · 1372 days ago

  I'd argue this isn't a cryptography problem, or at least not a purely cypto problem. Because we have the exact same issues with almost all file formats and storage mediums. It requires a maintenance toil task to make the occasional conversion from unsupported cyphers to supported cyphers. Maybe the page needs a second button and JS function - re-encrypt.

• tomjen3 · 1372 days ago

  The code uses AES. Likely that will remain for longer than most secrets are relevant.

• maqp · 1372 days ago

  XChaCha20-Poly1305 will probably never go out of fashion. Argon2 is only making itself in, phasing it out will take decades. OTOH you have a point in that the author's implementation PBKDF2 is being used, and that should already have retired a decade ago.

Doesn't require any special software. Just a browser.

if you've got to communicate the decryption key separately anyway, might as well just use password protected zip files, no?

• mprime1 · 1372 days ago

  Indeed, it's functionally similar to password-protected PDF or ZIP for some use cases . You should probably not treat password-protected zips as secure: https://security.stackexchange.com/questions/35818/are-passw...

  • maqp · 1372 days ago

    The argument your answer makes discusses confidentiality issues with passwords in Zip-files, yet the Portable Secret application doesn't take any major steps or use best practices like Argon2 to solve "brute forcing the password" problem.

> Prior art > I came up with Portable Secret on my own, but I have since found a few projects that do something similar. > https://github.com/kaushalmeena/digi-cloak > If you are aware of other similar projects, please let me know and I’ll link them here. Digi-Cloak appears to be an in-browser steganography tool, but this project looks more like an encrypted pastebin (e.g., PrivateBin [1]). [1] https://privatebin.info/

I wrote a similar software for the same reasons. One goal for mine was that the generated output is small enough to quickly verify that the code sent to the browser is the one you expect. Total code size is under 100 lines. https://github.com/dividuum/html-vault

• mprime1 · 1372 days ago

  Neat! I knew I could not possibly be the only one that had this idea. Linked your project.

I made something similar a few years back when I was learning web dev. It's not nearly as polished, but I'd love to pick apart your code and see what design decisions we did similarly/differently https://9p4.github.io/hackna/ The big difference is that your project is self-contained in an HTML file, which I think is a much better design

• mprime1 · 1372 days ago

  Cool! Added a link to your project

  • TedDoesntTalk · 1372 days ago

    I did the same thing before WebCrypto by including an AES JavaScript library in the page. Nice work.

The main problem with this is that someone uses it outside of its intended use cases, which even cultured people are missing. Jokes aside, great hack!

• mprime1 · 1372 days ago

  Definitely intended for more technical audiences, lots of sharp edges.

  • fedeb95 · 1372 days ago

    Sure, that's clear. Mine was an appreciation comment, but all the comments stating all the potential issues don't get that you're not proposing it to the government.

snazzy. i think self-extracting archives (like 7z's sfx stubs) edges this out as it's one less dependency. Could you create a self-extracting archive for multiple platforms?

Works pretty well on Android! Unfortunately, today I learned that FireFox doesn't seems to support opening html files. When I download the html file FF isn't one of the options to open it. Only Chrome. Anyone know an way around this?

• EamonnMR · 1372 days ago

  On what OS? They're all slightly weird about file associations.

  • jck · 1372 days ago

    On Android. It is a known issue which Mozilla don't seem to intend to fix: https://github.com/mozilla-mobile/fenix/issues/7546

• jck · 1372 days ago

  There is no workaround: https://github.com/mozilla-mobile/fenix/issues/7546

This would make a great 2600 article.

• mprime1 · 1371 days ago

  Thank you for saying so. I've been noodling with the idea of trying to submit a HOPE talk.

This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure). Passwords: - Easy to memorize. Pro: Does not rely on a device, can be recovered if devices stolen. - Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret. - Easy to brute force. Con: Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption. This will work for certain power users. Cryptography: - Uses current state of art algos. Pro: Resistant to access by known methods. - Will become obsolete. Con: Eventually the secrets will become exposed due to advances in crypt-analysis. Mitigation: Don't store anything to remain secure for decades, shorter lived is okay. - Secrets are encrypted once. Con: Any issue (there have been many) in WebCrypto implementation at time of encryption can not be fixed by browser upgrade (because of secret caching). - Secrets can be extracted from page and cracked elsewhere offline. Note: Security features such as timers, throttling, guess limits can not be enforced. They must be implemented e.g. in PBKDF. Client Side Security: - Cached objects. Note: For example a web page with browser vulnerability can walk JS objects and get existing secrets. Browser may also cache secrets, passwords, inputs, images to disk where they are not protected. - Web Browser WebCrypto and Same Origin Bypasses. Pro: Browsers have updates and are constantly being improved to enforce security model. Con: The direction the W3C goes in future (tens of years) is not certain and security model may change. Implementation issues in browser web APIs and Same Origin (common) can put secrets at risk. - Secret hosting. Con: Hosting content on other servers (e.g. github) may not allow management of access control. For example hosting on one subdomain could now or in future allow JS on sister pages to interact with page and the resources loaded, enabling side-loading attacks in JS. This may not be in control of victim if they uploaded their secret to be hosted by another party. - Trusted hosting. Con: Any untrusted source of HTML can steal the secrets, e.g. by serving malicious javascript along with the secret. This means the security of the hosting party and trust in the hosting party is required. (Note: this con was added in an edit)

• admax88qqq · 1372 days ago

  > Con: Eventually the secrets will become exposed due to advances in crypt-analysis You can claim this con for literally any crypto. And I'm not actually sure it's a reasonable assumption. Block ciphers seem to be pretty unbreakable so far. Even good ol Triple-DES is secure in practice barring some caveats (don't encrypt more than a certain amount of data) I'd wager if I gave you a real world message encrypted with AES with a strong key it won't be broken in our lifetimes.

  • createdapril24 · 1372 days ago

    That's a good point, I wasn't very specific about this (trying to keep it concise). To be specific here, the con is that there isn't what the industry calls Cryptographic Agility. https://en.wikipedia.org/wiki/Cryptographic_agility . It is not true this con applies to all cryptography (e.g. look at TLS). It has more to do with how cryptography is configured, parameters are negotiated and keys are managed, than with point-in-time choices about algorithms. The con here is that unlike other deployments of cryptography, this one doesn't have parameter negotiation and key management - and therefore doesn't have cryptographic agility. Re: "I'd wager that... AES..." is a also a good point. Modern cryptography has shown to be robust for decades and past their deprecation point. However, as you said, it IS a wager. There have been catastrophic failures of cryptographic primitives in the past. The con of this system is you will need to make a wager and tie yourself to the fate - you can't mitigate the risk if the catastrophic event comes or appears to be coming to pass.

    • woodruffw · 1372 days ago

      Contrary to what Wikipedia says, I don't think agility is considered a desirable property by most cryptographers: you still have the "attacker stored encrypted material" problem, and now you have to worry about downgrade attacks. Many of the most interesting/effective attacks on SSL/TLS have been downgrade attacks that stem directly from the protocol's (historically) agile design.

      • createdapril24 · 1372 days ago

        I disagree with your speculation as to what most cryptographers think. Are you basing this on any data you can share? Please also see the other thread about how this secret storage system is different from a communication protocol. Namely, communication protocols have a two step attack: first attacker must MITM and record ciphertext, then they must wait. This secret storage method is different (one step attack): attacker looks for ciphertexts on either targeted or non-targeted basis that use old standard. Persistence, caches and publication of these secrets has been done for them. It's a good point about downgrade attacks. They have been brutal for TLS to deal with.

        • woodruffw · 1372 days ago

          > I disagree with your speculation as to what most cryptographers think. Are you basing this on any data you can share? No, just conversations. I'll admit it's just speculation. Maybe I should qualify: there's "cryptographic agility" in the protocol sense (a single version of a protocol can accept a wide range of primitives, with the idea being that users can upgrade their primitives as old ones become insecure), and there's "cryptographic agility" in a more abstract design sense: wire formats, etc. should be devolved from the primitives in such a way that the protocol can be switched to secure primitives without requiring unrelated changes, and in a way that doesn't surface any differences to the user. To my understanding, the first sense of "cryptographic agility" is widely discouraged: we've yet to figure out a really reliable way to provide backwards compatibility without enabling malicious downgrades. The second sense is not something I've heard people use the phrase "cryptographic agility" for, but that's possibly just ignorance on my part. If that is indeed another form of agility, I believe that's widely considered to be good design (and this design is "agile" in that sense, since existing messages do not compromise the security of an upgraded scheme).

    • admax88qqq · 1372 days ago

      Agility does nothing to stop the "ciphertext from the past is broken due to crypto improvements". It's just a means to shorten response time to crypto breaks for _new_ traffic. This project is plenty agile, upgrading the primitive is very easy as it's not a communication protocol but a data at rest protocol. > this one doesn't have parameter negotiation and key management You're thinking in terms of live communication protocols between endpoints. There is no "parameter negotiation" when you are both the sender and receiver of a static ciphertext. There is no existing remediation for protecting your existing ciphertexts against future cryptanalysis.

      • createdapril24 · 1372 days ago

        I really do hear what you're saying and think you're making a great point. The part that I think applies is that this is a "data at rest protocol". Communication protocols are assumed (but maybe shouldn't be - a la PRISM disclosures?) ephemeral. As an attacker, I need to have been in the middle for that specific instance of the communication, and save it for decades, to attack it. Crypto agility shortens the window from a break or weakness to a fix, forcing any adversary who has not already recorded communication traffic to do so in a hurry. In this setting as a "data at rest" protocol, the work to persist the ciphertext has been done for the attacker. If there's a weakness or break it's up the defender to clean up all copies of the old secret ciphertext that's out there and publish new ones. In cases where the secret has been cached (e.g. Wayback Machine) that may not be possible. I hope you agree with this nuance that there's something the defender needs to consider. I agree with you that not all defenders will find this consideration will be decisive in their decision to use this method or not.

        • admax88qqq · 1372 days ago

          I just think it's a misleading analysis to say "this system is vulnerable to XYZ" without including the fact that ALL systems in this class are equally vulnerable. Crypto agility is not a thing that can be applied to encryption at rest. It's similar to criticizing an alcoholic drink by saying "this drink will cause liver damage" as opposed to saying "this drink, like all alcoholic drinks, will cause liver damage" Without that caveat people will see that criticism as evidence that other alcoholic drinks do not cause liver damage. The absence of words can convey the wrong impression. *Edited for better clarity.

          • createdapril24 · 1372 days ago

            At this point I can not edit the top comment. I would have edited with something like: "this property is not an implementation bug but a design outcome shared with any deployment of cryptography that persists ciphertext data in public." Of course in future I will endeavour for more clarity and hope others read into this thread.

• throwaway0x7E6 · 1372 days ago

  > Con: Any issue (there have been many) in WebCrypto implementation at time of encryption can not be fixed by browser upgrade (because of secret caching). has there ever been an issue that made WebCrypto produce invalid ciphertexts/hashes/PBKDF output?

• mprime1 · 1372 days ago

  Thank you for the comment and thoughts. Agree with most, disagree with some (easy to brute-force?), but I wanted to comment on this in particular: > Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret This to me is the most glaring "vulnerability". i.e. I use this to exchange letters with my friend Bob. Now someone impersonates me and sends a fake 'PortableSecret' to Bob that siphons out the actual password. Clearly this is a valid vector of attack, and one I made no attempts at defending from. The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous. I have to keep reminding myself this is a real vector, but the fear is irrational. As they say at DEFCON to people too concerned using their devices: "Nobody is wasting their 0day on you". I don't think I'm a target valuable enough to attract this kind of attacker.

  • createdapril24 · 1372 days ago

    I agree that each person/organization should look at the security properties of a system and assess their risk against what technology is appropriate. It's entirely reasonable that as a non-targeted person with low value secrets, many of the attacks here don't have ROI for a potential attacker and as a result are neither likely or impactful. What's important is that other persons and organizations who may be targeted - that they choose what technology to use, knowing what kinds of attacks are possible. For example a human rights activist might very well be targeted by phishing attacks and choose not to store secrets by this method. I am just trying to enumerate the properties so that persons/organizations can evaluate a match to their use case. I don't believe any system is perfect for all use cases and I don't hold any system to such a standard.

  • createdapril24 · 1372 days ago

    mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.

  • pwg · 1372 days ago

    The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force": "Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption" The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and again that "users will choose poor passwords" if left to their own devices to do so. The 'easy to brute force' part then comes in as "for those users who choose poor passwords, this rig linked below will brute force their passwords pretty quickly": https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... Note that the above performance page is a few years old, updating it for 8x of a newer Nvidia GPU should result in even more impressive performance numbers. And in all fairness, any cryptography where a user chooses a poor password is then vulnerable to "easy to brute force" by a rig such as the one above. Not because the encryption algorithm is easy to brute force (usually it is not) but because the user picked a poor password, and that poor password itself is easy to brute force.

    • mprime1 · 1372 days ago

      Right, agree with all of that. I would have characterized as "user can shoot themselves on the foot (i.e. by choosing weak password)", rather than "easy to bruteforce"

      • createdapril24 · 1372 days ago

        It's a perspective difference. Each individual user perspective: "It is possible I can shoot myself in the foot, and also possible I will not. It is not correct to say I will shoot myself in the foot.". Outside observer perspective: "Empirically, many users shoot themselves in the foot using this system. It is correct to say this system does not make feet safe". It might be phrased better in terms of safety than security? The safety of the system is left up to the users, and is - to the best of our knowledge - not safe to use _as is_ by most people.

      • kortilla · 1372 days ago

        But users choosing a weak password on a standard rate limited service login is significantly different to choosing a poor password in something that the attacker has unlimited, low latency and undetectable attempts against.

        • createdapril24 · 1372 days ago

          I agree with the point about unlimited and undetectable. I think there's nuance to low latency. Here the latency the attacker is limited by the amount of parallelism they can bring to bear on e.g. PBKDF. Ultimately this is an economic consideration about the cost to protect a secret vs cost to crack it.

  • kortilla · 1372 days ago

    > The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous. Don’t delude yourself. These phishing pages with mirrored login portals happen to podunk organizations all of the time. If someone manages to get a link to your page and is interesting in the contents, duping it and sending a phishing link to the suspected password holder is a trivial spear phishing attack (with an annoyingly high success rate).

• maqp · 1372 days ago

  >Uses current state of art algos. Pro: Resistant to access by known methods. AES-GCM is fine sure, but the password hashing function PBKDF2-HMAC-SHA1, i.e. what turns the user's weak password into the AES-key, is the opposite of state-of-the-art in this case.

  • SgtBastard · 1372 days ago

    Argon2-HMAC-SHA512 more like it? Or something else?

    • maqp · 1372 days ago

      Argon2 is built on top of BLAKE2 but the hash function isn't what's making it so effective, it's memory hardness, i.e. it fills the RAM when deriving a key from password, which makes massively parallel attacks impractical because GPUs / ASICs don't have petabytes of RAM just lying around.

      • SgtBastard · 1371 days ago

        Cool thank you - thought so, but always good to check :)

  • bobkazamakis · 1372 days ago

    Please share this silver bullet pake with the rest of the class?

>Some secrets don’t belong in your password manager. Things like backup private keys, 2FS recovery keys, wallet keys, safe combinations, treasure maps, etc. Uh, I put everything in my Keepass safe, then write the password down in an envelope in a secure location in my house.

I've been thinking about something similar, it really should be much easier to send encrypted messages. I'm not sure if this is a problem, but one thing that is unclear to me is how/if this protects against an adversary that can modify the html file. If the adversary can modify the HTML file in transit they can just add some code that sends the password to the adversary's server when the real recipient opens the file. (Of course, the recipient can run it in some air gapped browser etc, but that limits the practical use case quite a lot.) And if you want to use this to send messages over e.g. email this seems like a somewhat important thing to protect against. I guess you could send the portable secret html file separately, and then the user copy-pastes the message in some text-box, but again this makes it more clunky.

• mprime1 · 1372 days ago

  Phishing is indeed the most glaring vulnerability of this. While it's very real in theory, I am not concerned in practice. If I am the target of a sophisticated attacker, there are easier and more effective ways to pwn me. A few other comments reference the same, e.g.: https://news.ycombinator.com/item?id=34085245

  • forgotpw2726 · 1372 days ago

    Fair enough, I guess in many ways I agree that at least for now it is not a real world problem. But if this would become popular it wouldn't be that hard to make a proxy that silently adds some code to the page if you fetch it over the internet. Maybe it would be good to document this a bit more clearly that this mainly protects against weak adversaries. On the website you make some comparisons to GPG etc, which is a very different level of protection from my understanding, and may give a false sense of security. I think I would prefer an approach where each person has their own html file, and then they can copy-paste the message into a text box and then decrypt it. Then you could also use public-key cryptography etc, and store a (encrypted) private-key in the html file itself. Like a light-weight GPG client in a single static html page. I guess the main feature that I don't see how to add is how to store and keep track of the public keys for your friends in a nice way.

This seems like a really good proof of concept to let browser vendors know they could create a super useful utility in their browsers. I mean, it's very cool all on it's own, and great job in building it! I'm just hopeful that someone is taking notes.

• mprime1 · 1372 days ago

  Thank you!

> Crack me if you can This reminds me of LifeLock CEO's Todd Davis public challenge [1] when he revealed his Social Security number prominently on his site and billboards with overconfidence that his identity cannot be stolen but, unfortunately, he's been a victim of identity theft at least 13 times. 1. https://www.wired.com/2010/05/lifelock-identity-theft/

• nashashmi · 1372 days ago

  He also ended up leaving the company after it was learned he was guilty of a previous felony for identity fraud.

  • stickfigure · 1372 days ago

    Do you have a reference for this? The internet doesn't seem to know anything about it. I suspect it is false.

    • nashashmi · 1372 days ago

      https://www.phoenixnewtimes.com/news/lifelock-former-exec-an... Apparently it was the other cofounder. I confused the two.

• mprime1 · 1372 days ago

  I'm not that confident in my tool. That said, I ask myself every day if having my public identity associated to my project, website, etc. Was a good idea. It certainly helped with jobs in the past, but it's scary to hear stories of devs impersonated by others.

  • redbell · 1372 days ago

    > Portable Secret is not a product and it is barely a project You are such a humble person as you clearly stated why this thing was built. I am, in no way, claiming that you are too confident in your work, despite it being a cool project that can be used by privacy-aware techies. Your expression Crack me if you can just triggered LifeLock's story from the deepest part of my mind.

  • cryptonector · 1372 days ago

    Your tool would be safer if you used CBC (with some MAC) rather than GCM as the cipher mode, so that key & IV reuse would not be as dangerous. That said, since you generate a different salt and IV every time, the likelihood of key & IV reuse is very low, and having to implement an AEAD cipher mode by generic construction would be somewhat annoying. So I think the choice of GCM is fine enough.

    • mprime1 · 1371 days ago

      I started with CBC (without MAC) and upgraded with GCM since it was a more convenient way to provide integrity without adding the MAC step manually. I should really make sure IV/Salt are regenerated automatically after use. (there is a small print warning in the creator about reuse)

      • cryptonector · 1371 days ago

        > I should really make sure IV/Salt are regenerated automatically after use. Good idea. > I started with CBC (without MAC) Oof, you really didn't want to do that :) Glad you upgraded to GCM.

Any way to make this work with passkeys?

• jrmann100 · 1372 days ago

  Currently, WebAuthn/Passkeys are only designed for signing; you could re-use a challenge to be signed, but then the signature is as secure as a password (i.e., your Passkey would produce the same signature every time.) WebAuthn also only works in secure contexts (HTTPS)—you couldn't make it work in a plain .html file.

Nice idea. password protected zip files are portable too.

• mprime1 · 1372 days ago

  But not secure... https://security.stackexchange.com/questions/35818/are-passw...

One possible attack is someone changing either the encrypt or decrypt source code, either via Github (if they get access to the OP account) to log keystrokes. Or if someone has hosted it themselves then hack that hosting provider. Or they could do something like this: https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha... Phishing is another potential one. Browser extensions, or supply chain attack on packages they use.

• mprime1 · 1372 days ago

  I agree phishing is the most scary vulnerability for this. In practice, when exchanging emails with my mom, I'm not concerned about it. A sophisticated attacker has many easier ways to get into my stuff than creating a fake PortableSecret. (more detail in a different comment: https://news.ycombinator.com/item?id=34084887 )

  • quickthrower2 · 1372 days ago

    If you get 100,000 people using your site to exchange secrets, the bounty got a lot bigger. For phishing you and your mum might be immune, but one of the 100,000 might get phished. For taking over the account (which is now more juicy, could be some bitcoins there) then everyone would be vulnerable who doesn't check the source code each time they load the page.

    • mprime1 · 1371 days ago

      In order to have 100'000 potential victims, you need to have an attacker that knows 100'000 users using this and details of how what they do with it in order to convincingly phish them. That would be a very sophisticated attacker. So back to my original point. Beside. The README states pretty clearly this is 'demo' tech. Learn the trick and use it on your own. Depending on my GitHub tool for your critical secrets is not a good idea.

Cool project! This stuff is all possible thanks to the SubtleCrypto API ( https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... ), which became widespread in browsers in the last ~5 years. It's so great we don't have to use weird libraries (some with pretty gnarly side channel leakage) to do cryptography anymore. It wouldn't be that crazy for the browser to do the encryption part for me, right? Like, what if in the 'save this page' dialog my browser actually did the encryption, and then generated this 'self-decrypting page' for me if I checked a box saying "encrypt with password"? Would be a nice way for regular non-technical people to encrypt things and send them to each other.

• mprime1 · 1372 days ago

  I suppose that's a different implementation of the same 'hack' demo'd here, with the encryption carried out by an extension.

• distcs · 1372 days ago

  What level of confidence is there that all this API will work exactly as it works now after 30 years? I am concerned that they might at the very least deprecate and remove the ciphers used to encrypt my data in portable secret. Worse what if they remove support for the API? Then I am going to have HTML files with data I cannot decrypt anymore, right?

  • delaaxe · 1372 days ago

    If you’re worried about “30 years from now” you might as well store the decryption software alongside the message