Lainesc's recent activity

  1. Comment on Passkey vs smart use of passwords in ~tech

    Lainesc
    Link
    I've been trying to figure out how passkeys work under the hood. That's proving a bit difficult since most information about them is focused on informing users about how easy they are to use and...
    • Exemplary

    I've been trying to figure out how passkeys work under the hood. That's proving a bit difficult since most information about them is focused on informing users about how easy they are to use and how passkeys make it look like you're logging in with you fingerprint or facial recognition. But here's the big benefits from what I've been able to gather:

    1. Passkeys use public key encryption which is more secure than a password. The benefits of passkeys mostly stem from this. The service sends some random data to your device, your device encrypts it with the private key and sends the result back to the service, and the service decrypts it with the public key. If the decrypted result matches what the service originally sent, then the service knows you have the private key that correctly matches up with the public key they expected and it's a successful login.
    2. The encryption key itself never leaves your device and can't be intercepted like a password can. The most an attacker could get is a one time use response. Even when you set up a passkey, your device is the side that generates the encryption keys and the public key gets sent to the service. This means that even if an attacker gets in between you and the service, then all they get is the ability to verify if a sign in attempt is valid.
    3. A passkey's encryption key is almost certainly longer than a password you generate (this EFF article says 100-1400 bytes - realistically passwords are ~1 byte per character). Probably longer than many services allow a password to be.
    4. When a service's user database gets compromised, they only get the public keys. Theoretically that can allow them to more easily pose as the service, but they'd also have to get control of the domain (which is a lot more obvious).
    5. Password managers have a kind of built in domain validation with autofill, but this relies on you to manually set the domain. I'm sure everyone has run into services that use multiple domains for logging in, so you end up having to override that which creates a potential opening for an attack. Passkeys require the service to correctly set up domains when setting up the passkey. If the domain on the passkey doesn't match, then it doesn't work. There's no way to override it.

    Longer term, passwords are going to have to be longer and longer as computers get more powerful. Eventually they’ll have to be so long that we can’t be expected to remember them (though I have no idea what the projected timeline on this is). Getting people to use a password manager isn’t really an option - people see all of their passwords in one place and can’t believe it’s secure. Passkeys are a potential solution for this. Using public key encryption is an added benefit that makes them even better than long passwords.

    32 votes

  2. Comment on Original ‘Looney Tunes’ no longer available on Max in ~tv

    Lainesc
    Link Parent
    That’s what it sounds like to me: Or at least that’s the way it was publicly presented.

    That’s what it sounds like to me:

    “We all love HBO, and it’s a brand that has been built over five decades” to stand for “edgy, groundbreaking entertainment for adults,” Perrette said. “But it’s not exactly where parents would most eagerly drop off their kids. And yet Warner Bros. Discovery has some of the best-known kids’ characters, animation and brands in the industry. Not surprisingly, the category has not met his true potential on HBO Max.”

    Or at least that’s the way it was publicly presented.

    3 votes

  3. Comment on TRMNL - Open source e-ink "companion" device in ~tech

    Lainesc
    Link Parent
    I'm using a 7" Inky Impression with a Raspberry Pi Zero W. It takes ~5-10 seconds to process the image before the screen starts to refresh. The core of the script is this function: from PIL import...

    I'm using a 7" Inky Impression with a Raspberry Pi Zero W. It takes ~5-10 seconds to process the image before the screen starts to refresh. The core of the script is this function:

    from PIL import Image
from inky.auto import auto

def display_image(image_file_path):
    inky = auto()
    image = resize_image(Image.open(image_file_path), inky.resolution)

    inky.set_image(image, saturation=1)
    inky.show()

    And resize_image is copied from this old (now removed) function in Pillow. I found the photos looked terrible until I added saturation=1. It's not as good as a real photo print or a good LCD screen, but it's certainly not bad. With a few feet of distance, the dithering is much less noticeable.

    I'd love to get a bigger one, but yeah, I'm not paying that much. I wish e-ink weren't so expensive.

    4 votes

  4. Comment on TRMNL - Open source e-ink "companion" device in ~tech

    Lainesc
    Link
    I hope they release a color e-ink version of this. I have a color e-ink display hooked up to a Raspberry Pi as a digital picture frame, and it works really well. But it’s a bit annoying to add...

    I hope they release a color e-ink version of this. I have a color e-ink display hooked up to a Raspberry Pi as a digital picture frame, and it works really well. But it’s a bit annoying to add photos to it and it requires things like manually updating the OS (and fixing scripts that break during updates). This seems like it would be a much more user friendly option.

    2 votes