snagg

9 ms·

31.
Show HN: Granular access control and authentication for Docusaurus(npmjs.com)
4 points by snagg 3y ago|0 comments
32.
by snagg 3y ago
We are big proponent of app-layer encryption as well. We wrote extensively about how we do it for our specific use case: https://www.slashid.dev/blog/app-layer-encryption/
33.
by snagg 3y ago
Hi, sorry for the late reply, just saw this. Do you mean to have certain pages public while others are private? If so, yes. You can make login optional (using the slashID.forceLogin parameter. See here: https://github.com/sl
34.
by snagg 3y ago
The short answer is that it's non standard and it depends on where the passkeys are stored. To be precise, the original WebAuthn standard did not account for a recovery mechanism at all and instead recommended adding multiple credentia
35.
by snagg 3y ago
We spent some time putting together a threat-model and taxonomy of attacks paths for Passkeys in case anybody is interested: https://www.slashid.dev/blog/passkeys-security-implementatio... Passkeys are definitely a lea
36.
by snagg 3y ago
This is an area with the specs contrast with the vendors. The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable. Apple and other vendors
37.
Passkeys: Threat Modeling and Implementation Considerations(slashid.dev)
9 points by snagg 3y ago|0 comments
38.
by snagg 3y ago
Hi, I'm the author of the SlashID blogpost. You are right, the WebAuthn standard doesn't provide any guarantees on the authenticator storage security hence passkeys (and WebAuthn creds) can be stored in anything that speaks CTAP2.
39.
by snagg 3y ago
Hi, I'm the author of the blogpost. You are spot on, Passkeys are exportable so the private key ends up both on iCloud and the Enclave/authenticator. My understanding is that there's chatter about cross-vendor synchronization
40.
by snagg 4y ago
Thank you! 100% agree - realistically, given their scale, the tradeoff made sense. The UI would have been fairly un-intuitive for users had they left the option to do both device-bound keys and passkeys.
41.
by snagg 4y ago
Happy to chat more about it if you'd like!
42.
by snagg 4y ago
We wrote a long post on Passkeys, in particular how they are implemented by Apple[0] that might be interesting. Technically a Passkey is just a multi-device FIDO credential that is compatible with WebAuthn (which is an official W3C and FIDO
43.
In-Browser HSM-Backed Encryption with Tink and WASM(slashid.dev)
1 points by snagg 4y ago|0 comments
44.
OpenAI's DaVinci-003 for Reverse Engineering(github.com)
1 points by snagg 4y ago|0 comments
45.
Securing internal web apps at Figma(figma.com)
1 points by snagg 4y ago|0 comments
46.
by snagg 4y ago
Hi HN - We are excited to launch Data Vault and help developers address compliance and secure storage easily. Our team would love to get your feedback and answer any questions!
47.
Show HN: HSM-backed PII storage directly from the front end(slashid.dev)
6 points by snagg 4y ago|1 comments
48.
App-layer cryptographic primitives for secure storage of user data(slashid.dev)
2 points by snagg 4y ago|0 comments
49.
A deep-dive on Apple's passkey's implementation(slashid.dev)
1 points by snagg 4y ago|0 comments
50.
by snagg 16y ago
You are missing the point: is there anything of the above that can't be done without a third party having access to the encrypted content vs having a simple hash of the email/poc sent to the vendor?
51.
by snagg 16y ago
>No, that doesn't actually solve this problem because then it just turns into a he-said-she-said. then I fail to understand what you plan to do with the encrypted stuff that you get from the researcher since the only one able to decrypt
52.
by snagg 16y ago
> They already do this. After a vulnerability is patched and fixed they release what it did. Usually researchers' submissions are way more detailed than the advisories you see from vendors. Meaning that you cannot just decrypt the conte
53.
by snagg 16y ago
I think this approach exposes a number of problems that are pretty relevant. First off vendors by decrypting the content of the researcher's submission are basically giving up vulnerabilities to the bad guys that want to target unpatched s