you are viewing a single comment's thread.

view the rest of the comments →

[–]fschmidt 7 insightful - 4 fun7 insightful - 3 fun8 insightful - 4 fun -  (50 children)

Why should I have a password manager when Chrome already remembers my passwords? All the scum running Odysee would have to do is generate a password for me.

Actually the whole idea of passwords is retarded. On my sites one just enters one's email and gets a link with a hash that sets a persistent cookie. No need for annoying passwords.

[–]Chipit 12 insightful - 6 fun12 insightful - 5 fun13 insightful - 6 fun -  (9 children)

Well, if you can trust Google, the organization dedicated to sucking up your personal data, to keep your passwords safe than we can all rest easy.

Actually the whole idea of passwords is retarded.

OK. (laugh track)

[–][deleted]  (3 children)

[deleted]

    [–]JasonCarswell 1 insightful - 3 fun1 insightful - 2 fun2 insightful - 3 fun -  (2 children)

    Build it and they will cum.

    [–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

    This is a lie!

    [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (0 children)

    Everything I've ever spooged on was built.

    [–]fschmidt 4 insightful - 5 fun4 insightful - 4 fun5 insightful - 5 fun -  (4 children)

    What a moron. Now I understand your previous comment.

    [–]AXXA[M] 5 insightful - 4 fun5 insightful - 3 fun6 insightful - 4 fun -  (2 children)

    /u/fschmidt please think of the Pyramid of Debate when you comment, and if you are going up or down it. Please don't drag discussion down on the Pyramid of Debate.

    /s/SaidIt/comments/j1/the_saiditnet_terms_and_content_policy/

    [–]fschmidt 4 insightful - 4 fun4 insightful - 3 fun5 insightful - 4 fun -  (1 child)

    Where on the Pyramid of Debate is this?

    OK. (laugh track)

    I don't think I went down from there.

    [–]AXXA 3 insightful - 3 fun3 insightful - 2 fun4 insightful - 3 fun -  (0 children)

    possibly

    [–][deleted] 3 insightful - 5 fun3 insightful - 4 fun4 insightful - 5 fun -  (0 children)

    If it took you that long... Come on dude.

    [–][deleted] 6 insightful - 5 fun6 insightful - 4 fun7 insightful - 5 fun -  (18 children)

    Actually the whole idea of passwords is retarded. On my sites one just enters one's email and gets a link with a hash that sets a persistent cookie. No need for annoying passwords.

    😮 sounds pretty awesome

    [–]raven9 6 insightful - 4 fun6 insightful - 3 fun7 insightful - 4 fun -  (9 children)

    It's not really very awesome. It just means you have to sign into your email instead to receive the link... Steve Gibson invented a good solution but I have yet to see anyone implement it.

    When you sign up, your app would generate an encryption key pair and send the public key to the host site. They store that key. In future, whenever you log in, you just enter your username. The site responds by using your public key to encrypt some random text which it sends to your app. Your app uses your private key to decrypt it and sends the plain text back to the site, encrypted with your private key. The host site decrypts it with the public key. If it matches the random text they encrypted and sent, you are logged in. No need to remember any passwords.

    [–][deleted] 4 insightful - 4 fun4 insightful - 3 fun5 insightful - 4 fun -  (6 children)

    Schmidts email approach has an advantage in that everyone already uses email and can understand it. I believe he's making a larger pitch that some casual accounts just don't need to be very secure.

    [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (5 children)

    Is there any interest in setting up a public/private key generating thing on SaidIt that could be used to log in on other platforms carrying our identities forward? Not sure it would matter too much with anons other than to verify you're the same "d3rr" on other platforms as on here, without getting direct communicated validation in comments or chat.

    [–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (3 children)

    Is there any interest in setting up a public/private key generating thing on SaidIt that could be used to log in on other platforms carrying our identities forward?

    This is basically oAuth. It's already running here for the android app. No one cares about additional uses for it. No one wants to make saidit the center of their digital identity.

    [–]JasonCarswell 3 insightful - 4 fun3 insightful - 3 fun4 insightful - 4 fun -  (2 children)

    No one wants to make saidit the center of their digital identity.

    I resemble that accusation.

    I take it oAuth is good or you wouldn't use it. Would it be of use to non-Android folks?

    [–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

    Yes oAuth has many uses. Sign in with Google, Sign in with Facebook, etc, those are all oAuth.

    [–]JasonCarswell 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

    Oh. I thought it was more indie. Last Feb someone (maybe Panzer) posted an alt-oAuth that sounded terrific. I wish I could find that again.

    [–]raven9 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

    You could create a key pair and publish the public key so then when you make a post anywhere else you could make a SHA1 hash of it and encrypt that and post it along with your post. Anyone with your public key could decrypt the hash and verify it matches their own hash of your post. That proves you are the one who encrypted it hence proof of the same identity. That would also mean other people could encrypt messages to you with your public key.

    [–][deleted]  (1 child)

    [deleted]

      [–]raven9 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

      Yes that sounds good too, I didn't know a signature can be verified with just a hash of the public key.

      [–][deleted] 4 insightful - 3 fun4 insightful - 2 fun5 insightful - 3 fun -  (7 children)

      That's how the Brave browser works too.

      [–][deleted] 4 insightful - 3 fun4 insightful - 2 fun5 insightful - 3 fun -  (6 children)

      I think I remember that, for their BAT doxing scam

      [–][deleted] 4 insightful - 3 fun4 insightful - 2 fun5 insightful - 3 fun -  (5 children)

      Uh oh, wasn't aware of that. I have had a pretty good experience with BAT, it's like getting paid $8 a month to use their browser. Not much, but it's handy for beer money.

      [–][deleted] 4 insightful - 3 fun4 insightful - 2 fun5 insightful - 3 fun -  (4 children)

      I'm just mad that their Uphold partner requires an ID upload. Maybe it's not a scam. But I'm under the impression that they don't need to know your identity until you make $10k, in compliance with those Know Your Customer laws. So Brave and/or Uphold* (I think it's an big and) is more strict than the law requires. I guess like here :(

      [–][deleted] 3 insightful - 3 fun3 insightful - 2 fun4 insightful - 3 fun -  (1 child)

      Ah the Uphold issues, I heard about those. So far no problems but reading about them wasn't real encouraging. My bank gives a fraud alert for transferring funds in.

      [–][deleted] 3 insightful - 3 fun3 insightful - 2 fun4 insightful - 3 fun -  (0 children)

      Hhahaha your bank is my new favorite bank.

      [–]JasonCarswell 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

      My offer still stands. I'd BAT for you.

      [–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

      It ain't me your looking for, babe

      [–]rubberbiscuit[S] 5 insightful - 4 fun5 insightful - 3 fun6 insightful - 4 fun -  (6 children)

      I am almost positive this is what Odysee does, at least as of a month ago when I signed up there.

      [–]raven9 5 insightful - 4 fun5 insightful - 3 fun6 insightful - 4 fun -  (4 children)

      Yeah Odysee does that. Github started doing it too. It is very much a nuisance having to sign in to email to get that link every time.

      [–]fschmidt 4 insightful - 4 fun4 insightful - 3 fun5 insightful - 4 fun -  (0 children)

      I think rubberbiscuit meant that Odysee now generates a password.

      With my email system, the cookie is persistent so you just need to do this once.

      [–][deleted] 3 insightful - 3 fun3 insightful - 2 fun4 insightful - 3 fun -  (2 children)

      Freaking Github man, what do they even know about coding, right? XD

      [–]raven9 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

      I never suggested they don't know about coding. I said their login method is a nuisance.

      [–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

      I was being facetious. I was hinting at the fact that a lot of open source programming projects are on Github. And I agree, it is annoying. I figured they knew something I don't about these things.

      [–][deleted] 4 insightful - 5 fun4 insightful - 4 fun5 insightful - 5 fun -  (0 children)

      Maybe fschmidt refers to the 12-word seed for the crypto wallet???

      [–]L_X_A 5 insightful - 4 fun5 insightful - 3 fun6 insightful - 4 fun -  (8 children)

      On my sites one just enters one's email and gets a link with a hash that sets a persistent cookie. No need for annoying passwords.

      That's a cool concept.

      If I understood you correctly:

      1. The user first enters his email address on your site to login/register.
      2. Your server then generates a nonce (say, 128-bit, Base64 encoded) and associates it with that email address.
      3. The nonce is then sent to the user's email as the parameter of a hyperlinked URL (e.g. fschmidt.cool.site/authn/ZnNjaG1pZHQncyBzaXRl)
      4. Your server checks the nonce for a) an associated email, and b) the time elapsed since generating the nonce and the endpoint call (say, less than 10mins)
      5. If all checks pass, you produce a long(er) lived cookie to be used as a bearer token by the user agent (browser, app, etc.)

      Which means that the user's email service is the de-facto (albeit indirect) authentication provider.

      Cookies should not be valid indeterminately. You'd just be spreading that attack vector wide open. With that in mind, how would you deal with a user who has been inactive past the cookie's expiration date? Do you just send them a new URL containing a new nonce? How do you prevent an attack where nonces are requested repeatedly? Heuristically through API management or do you simply cap-and-throttle?

      [–]fschmidt 5 insightful - 4 fun5 insightful - 3 fun6 insightful - 4 fun -  (5 children)

      My server generates a crypto hash (MD5 for now) of concat(email,secret_salt) and sends that in the URL to the user's email. That link then sets 2 persistent cookies, the user's email and the hash. So the server doesn't need to store anything and can verify the cookies. On a HTTPS site there is no way for this to be broken, so I see no problem with making the cookies persistent. What problem do you see? The only possible leak is the email itself, but that problem applies to all password systems anyway.

      [–]L_X_A 5 insightful - 3 fun5 insightful - 2 fun6 insightful - 3 fun -  (4 children)

      The problem with perennial cookies are multiple. From the top of my head, the main ones relate to either someone stealing the cookie on the client (e.g. through javascript if you don't set the HTTPOnly flag), or the user logging in from a machine someone else has access to (e.g. library), or the user trying to connect to your site from a public network (hotel, Starbucks, etc.) and falling victim to an MiTM attack (no, HTTPS would not help you in this scenario. Unless your are using mTLS you wouldn't know whether you are talking to the MiTM or the legitimate user).

      Also, depending on how you configured SSL, there are ways to downgrade it client-side so the attacker could sniff the communication even if they're not directly relaying information to and from the legitimate user.
      Examples: https://access.redhat.com/articles/1232123 and https://freakattack.com/

      But I think the perennial cookies are the least of our problems here.

      I'm assuming that:

      a) site_password is a static secret in your server which is used of all users. That is, user_1 gets MD5(concat(email_1, site_password)); user_2 gets MD5(concat(email_2, site_password)) and so on.

      b) The cookies themselves are not encrypted.

      If that's the case, with this simple attack I could impersonate all of your users:

      1. Register for your site with my email 1337.h4x0r@veryedgy.com
      2. receive MD5(concat(1337.h4x0r@veryedgy.com, site_password)) = myEmailDigest
      3. Run a parallelized MD5 crack, varying variable_salt on concat(1337.h4x0r@veryedgy.com, variable_salt)until I get myEmailDigest (with MD5 there are optimized ways of doing this).
      4. Now I know which variable_salt value will produce an MD5 hash which will be interpreted as legitimate by your server. Even worse, I potentially stumbled upon site_password itself. All I need now is a few more fake accounts and MD5(concat(fakeEmail, site_password)) results to be 99% sure.

      From this point on, I have deduced site_password and thus have access to all of your users' accounts because all of them are authenticated through site_password.

      I mean, it's good enough for a school/uni project. Or a site where it doesn't matter if one user can impersonate another (e.g. those "scrum poker" sites that don't require an account). But I wouldn't put it on anything which has persistent user data. Especially if it is used by people living in a country where GDPR applies.

      [–]fschmidt 5 insightful - 3 fun5 insightful - 2 fun6 insightful - 3 fun -  (3 children)

      These are valid issues. The javascript and MiTM attack issues are the least serious since they only risk exposing individual users. I don't see any solution for this with any system. A nonce just limits the time of exposure, nothing more. My sysadmin configured SSL and I assume he did it right. I have thought about the last issue you mentioned. I don't care for now while the sites are small and no one will bother. Later I would generate user passwords and store them in the user record and use that instead of a global salt, which solves this issue. If these things are addressed, I can still use persistent cookies. But I will worry about these issues in proportion to the size of the sites (number of users). In general, I don't have any site where security is really critical like a banking site would be. I don't keep credit card numbers or anything like that.

      [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (2 children)

      Can you add a little extra salt to make it seem a little more randomized? ie. Multiply the password by the/a time/date stamp or some other changing variable (title of current top thread title of FreedIt)?

      cc /u/L_X_A

      [–]fschmidt 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

      I thought more about this. What I will do is to generate a new password every time a user logs in. I will store that password in the database and include that password in the emailed URL. So no crypto or hash needed. And this completely eliminates the last problem that /u/L_X_A mentioned.

      [–]L_X_A 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

      If you want to prevent the attack I described and still not have to store the passwords/salt-values in your server, you could go the authentication through encryption route.

      Namely, you'd ditch the email and hash cookies for a single cookie containing the user's encrypted email address.

      • When the user registers with user_email, you send them an URL that will result in them receiving the cookie user-cookie = Encrypt(user_email, server_secret).
        I'd recommend a symmetric, strong (enough) cipher such as AES-256-GCM or ChaCha20Poly1305. You did choose MD5 as hashing algo earlier, and I'm assuming you did so for performance reasons. So it's up to you to judge which cipher would still accommodate your performance needs.

      • Don't forget to set the HttpOnly, Secure and SameSite flags.

      • On every request, the server would decrypt the ciphertext in the user-cookie's value using Decrypt(ciphertext, server_secret). If it matches the email of a user account, the authentication succeeded. Here's where you should watch out for your performance needs. This needs to be done on every request.

      This solves the following problems:

      • You are no longer storing (plaintext) user information in the cookie, thus compliant with GDPR (see: https://www.gdpreu.org/the-regulation/key-concepts/personal-data/)

      • If someone steals the cookie, they won't be able to know what's in there.

      • If you chose a decent cypher, a plaintext collision attack as I described earlier becomes unfeasible.

      This method still has the problem that every user's email is encrypted with the same key, though. So should someone be able to crack server_secret (very difficult depending on the cipher you choose, but still), they would be able to access every account they know the email of.

      To circumvent this, you could extend this pattern with a Diffie-Hellman-based KDF functionality:

      • On your server, instead of the symmetric key as stated above, you generate and store a secret prime number which will be used in a "deferred" Diffie-Hellman key agreement. That is: server_secretPrime

      • When the user registers, you generate an ephemeral secret prime for the user, and calculate the user's public prime: user_publicPrime.
        You then store the following cookies:
        ** The encrypted email address: user-access = Encrypt(user_email, DH_KDF(user_publicPrime, server_secretPrime))
        ** The user-specific public prime used for the Diffie-Hellman key agreement: user-prime = user_publicPrime

      • When you receive a request from the user, you use the values stored on the cookie to authenticate them: Decrypt(user_email, DH_KDF(user_publicPrime, server_secretPrime))

      This will ensure that a new key is used for every user, and it will not require you to store user-specific passwords in your DB.

      It still leaves singular users vulnerable to someone stealing their cookie and getting access to their account in perpetuity (user-access + user-prime will always produce a valid ciphertext).

      If you want to prevent this from happening, I see no other alternative than storing user_publicPrime in the DB and associating it with the user_email. Whereby you'd invalidate the cookie by generating a new value of user_publicPrime and storing it in the DB.

      If you do this, you could of course forgo the DH_KDF pattern altogether by simply saving user-specific server_secrets. Then again, you'd be storing cryptographic material in a DB. Not exactly something you want to do. With the DH_KDF pattern, you can keep 1 server_secretPrime stored somewhere secure, while user_publicPrime can be stored in the DB without concern.

      [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (1 child)

      > That's a cool concept.

      /u/d3rr, is this something that can be done on other platforms? Projex, Federated PeerTube, Lemmy, etc?

      [–][deleted] 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (0 children)

      Sure, you could hack an alternate account/login system into anything open source.

      [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (4 children)

      Why should I have a password manager when Chrome already remembers my passwords?

      Why are you using Google Chrome? You might as well use the new Microsoft Edge or Facebook's Panoptikunt browsers.

      I use Brave, Vivaldi, Waterfox, Palemoon, Falcon, (Opera, Firefox, when desperate) and currently Basilisk. They ALL have issues. Waiting for LibreWolf to rise.

      [–]AXXA 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

      I use Brave. What issues do you see with it?

      [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (0 children)

      Many folks have covered this. I'm personally not very worried about security thought perhaps I should start to be. With security, the biggest problem is not knowing what I don't know.

      Personally, my biggest issues with Brave are the lack of vertical tabs, tab management issues, and bloat. Plus, the bigger a FLOSS project gets, the more likely it will be infiltrated by Google, Microsoft, Facebook, etc. Firefox got cucked in this way.

      [–]fschmidt 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (1 child)

      I spend my days (except shabbat) doing web development for normal users, so I need to use the browsers that they use, and that is Chrome and Safari. Safari is horrible, so I mostly use Chrome.

      [–]JasonCarswell 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (0 children)

      Ooof. On a Mac.