328 reputation
111
bio website
location
age
visits member for 3 years
seen Jun 29 at 19:34

May
6
comment What makes Let's Encrypt secure?
@user54609: An active MiTM attacker only gets one chance (per certificate) to compromise Let's Encrypt, and must do so by compromising connection to Let's Encrypt (which is signed by a trusted CA). With a self-signed certificate, every connection is vulnerable to active MITM attack.
May
5
comment What makes Let's Encrypt secure?
@immibis: Self-signed certificates only protect against passive MITM attacks. An active MITM attacker can create a self-signed certificate.
Jul
7
awarded  Scholar
Jul
7
accepted Is code-signing with a non-ssl timestamp unsafe?
Jul
4
awarded  Student
Jul
3
asked Is code-signing with a non-ssl timestamp unsafe?
May
16
comment Why are certificates limited in time?
And even then, CRLs aren't fully reliable.
Mar
24
comment How can I prevent that my users get a certificate issued for my domain on my behalf?
Ah, this story brings back memories. CA: We need to do a phone verification. Me: Hi, I'm Brian. CA: Can you prove it? Me: Sure, here's my boss. Boss: I'm his boss. He's Brian. CA: Great, thanks! You're all set.
Mar
24
answered Is it possible to boot an encrypted server remotely and securely?
Feb
10
comment If I include a Forgot Password service, then what's the point of using a password?
Needing to trust both you and my chosen email server is not very different from needing to trust both you and my chosen openID provider...and in many cases a user's openID provider and email server are identical.
Sep
23
comment Could a user never store a password if a username/email hash was used instead?
A random javascript PBKDF2 implementation: anandam.name/pbkdf2
Sep
23
comment Could a user never store a password if a username/email hash was used instead?
@JohnDeters: As my proposal is about a browser extension, the use of PBKDF2 is feasible (and it's perfectly possible to implement PBKDF2 in javascript). And there's nothing stopping the extension's generated secret from being very complex. So, reversing the hash from via brute force would impossible (since the user's original password is mostly random, from the hacker's perspective, and thus there is no way to differentiate the password from other passwords which yield the same hash). This assumes the use of a unique private key, as mentioned in downside #4.
Sep
23
awarded  Editor
Sep
23
revised Could a user never store a password if a username/email hash was used instead?
added 438 characters in body
Sep
23
answered Could a user never store a password if a username/email hash was used instead?
Sep
23
comment Could a user never store a password if a username/email hash was used instead?
@bwheeler96: Running MITB is much more difficult. For example, running MiTM is often as simple as running a wifi hotspot and seeing who uses it (and hoping they don't use SSL). MITB attacks require tricking the user into downloading a vulnerable browser or taking advantage of an unpatched vulnerability.
Sep
20
awarded  Critic
Sep
20
comment Hide a machine on LAN
Is your intention to have machines connected to your wireless access point be segregated from your network but still have internet access?
Sep
20
comment Ensure web service only accessed by authorized applications
The downside of using a tried and tested algorithm to protect something that is inherently un-protectable is that tried and tested algorithms are more likely to have existing reversal algorithms. In traditional security, protecting the algorithm is unimportant; the goal is to use an algorithm that is safe (unless the key is known), even if the algorithm is public. If no such algorithm exists (in this case, because the key must be held on the client-side), security through obscurity is less unreasonable; there are no good choices.
Jun
25
awarded  Yearling