328 reputation
111
bio website
location
age
visits member for 2 years, 5 months
seen Nov 2 at 3:46

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
Oct
31
awarded  Citizen Patrol
Oct
30
comment How can I encrypt a file with .NET and have the same file size of the original file?
Just to emphasize Thomas saying you need integrity: If I am a man-in-the-middle and know you probably sent the message !JUNK!Please send $500 to Joe Smith!JUNK!, I may be able to change it to !JUNK!Please send $600 to Joe Smith!JUNK! Encryption w/o integrity prevents someone from knowing what was said, but does not protect you from someone changing what was said. Some of your message is probably predictable, so this is pretty dangerous.