Hacker Newsnew | past | comments | ask | show | jobs | submit | atoponce's commentslogin

The source code is open source. Please point to the lines of code where the backdoor exists.


Source code is open source doesn't mean squat for safety. Have you audited the code? Do you have the skills etc required to prove its not backdoored?

Because I know I don't have that skill set or time. I do have however some big fat red flags on using it because it was opted for by an entity whose entire existence is based around backdoors and spying.

Honestly i find it absurd that some folks say just because something is open source it's automatically safe. The vast majority of us whether the project is open source or not lack the skill or capacity to pick up on a well obfuscated hole. Hell even the best of us aren't that good.


You can't get right/left balance metrics with a single pod. Several old metrics are now applied to both feet, so you can compare right to left. EG, if you notice your right leg spring stiffness increasing, but not your left, you know the right leg is getting stronger, which might prompt you to increase the strength in your left leg. That sort of stuff.

But yeah. The goal is to get existing Next Gen Stryd customers to purchase a second Next Gen pod as well as a membership. But for older Stryd pod owners like myself, $250 for two Next Gen pods and a membership is a pretty sweet deal.


2FA is rife with problems. FIDO2/WebAuthn isn't tied to biometrics and can be inconvenient. TOTP can get out of sync and can be phished. Email can also be phished. Voice and SMS are vulnerable to SIM swaps. Now we're seeing that passkeys are horribly opaque without proper management and at risk of getting lost.

Le sigh.


Passkeys are just software backed FIDO keys with no attestation and less features.

FIDO is flexible enough to distinguish userPresence (I.e., touching the key) from userVerification (commonly, entering a PIN), but this is only defined for physical keys IIRC.


> FIDO2/WebAuthn isn't tied to biometrics

Good. Biometrics (“something you are”) aren’t a second factor.


Biometrics aren't the second factor when using WebAuthn, the hardware security key is. But anyone with access to the security key can use the second factor. Biometrics would tie the key to you preventing them from being used by others. The best we have right now for unlocking the security key are PINs, AFAIK.


All those problems are also true of 2FA's competition, which is plain old passwords. 2FA is progress. Don't let the perfect be the enemy of the good.


I was very disappointed in that Kickstarter. Yubikey ran a 54% off discount May 4th last year and not knowing when I would get my v2 SoloKeys, I purchased two. I had them within the week and have since integrated them into all my accounts.

I debated backing out of the Kickstarter as the Yubikeys were working so well for me, but decided to stick with it and see what the SoloKey experience would be like. Yeah, disappointing. I ordered USB-A and USB-C keys. The USB-A key doesn't make a good connection with the USB port. It needs to be carefully held to register with the OS, otherwise it doesn't get power.


Very structured with lots of very visible patterns in your JavaScript demo site. Some screenshots: https://imgur.com/a/2zQh4bA


His slides to his talk have been posted. I'll like the video to the talk when it's up.

https://tobtu.com/blackhat2022/


It's not my repo, so I don't know. I don't see any specific criteria, so if you see a project missing that should be added, send a pull request.


> https://articles.59.ca/doku.php?id=pgpfan:tpp

Some rebuttals to that critique outline that the author doesn't fully understand the arguments Thomas Ptacek laid out, and may have a simplified understanding of PGP:

https://lobste.rs/s/tyaze3 and https://redd.it/negkdl


What exactly is an OpenPGP recovery property? Can you point it out in the RFC?


OpenPGP specifies cipher feed back (CFB) mode[1] for block ciphers (normally AES). CFB has the inherent property that it is self healing in the face of corruption. It does not work in all possible instances of corruption but it works for the normal sort of corruption that is seen with mass storage devices (multiples of 512 bytes). A practical example here[2].

[1] https://datatracker.ietf.org/doc/html/rfc4880#section-13.9

[2] https://articles.59.ca/doku.php?id=pgpfan:agevspgp#encrypted...


I see. You're defining resynchronization of the register during decryption as recovery, not parity checks for recovering corrupted data. Fair enough.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: