211 reputation
15
bio website
location
age
visits member for 2 years, 10 months
seen yesterday

Jul
10
comment Is “the oft-cited XKCD scheme […] no longer good advice”?
@PTwr The NSA certainly uses vast amounts ASICs with fixed hardware that can do nothing but SHA1 (or MD5,..) in parallel. If you think a GPU is fast, just imagine something several orders of magnitudes faster with rather reasonable power consumption. Proof for how easy something like this is even for normal people are all those VLSI bitcoin miners out there. SHA1 with PBKDF2 is only a bandaid there, what you really want is something like scrypt that's designed to take lots of resources.
May
28
comment Is it good practice to ban an IP address if too many login attempts are made from it?
@Roy If the initial sequence number is predictable, the whole handshake is predictable. But apparently that did get better over the years. But see here for what I meant.
May
27
comment Is it good practice to ban an IP address if too many login attempts are made from it?
Don't forget the simple fact that I can easily (sadly really) spoof my IP address and get you to block IPs despite not having any access to it. Depending on your use case such a DDOS attack may be problematic or not.
May
23
comment Are random URLs a safe way to protect profile photos?
@Basic The definition of a secure cryptosystem hasn't changed since the 19th century (Kerckhoff's principle). It is secure if everything but the key is public knowledge. The key in our case is the URL. If I can increase my chances of getting to a file immensely just by having some good guess about when it was created (or creating a few files myself and observing the pattern to figure out the seed of the non-secure PNRG, then I can iterate through all files in the system!), the system is not secure. I just don't see the point of contention here.
May
21
comment Are random URLs a safe way to protect profile photos?
@Basic Umn.. have you actually checked how GUIDs/UUIDs are generated? That math assumes that all bits are randomly generated by a secure random generator which is completely wrong. That guy is basically computing the chances for a collision assuming a non-malicious hacker, which is completely different. For example type 4 UUIDs are generated usually using a non-secure random generator. After seeing some generated UUIDs it's then very, very simple to guess the sequence. The GUIDs based on a MAC are generated using a timestamp - you really don't see how easy it is to guess possible values?
May
21
awarded  Commentator
May
21
comment Are random URLs a safe way to protect profile photos?
@Basic If the problem is "make URLs unguessable" then no there's no much bigger problem than "system makes URLs trivially guessable" (otherwise why not argue that sequential numbers are fine too?). And yes some UUIDs use parts of a MAC address that obviously helps exactly until the attacker can get a single GUID (which is pretty much guaranteed), afterwards it's a simple timestamp they have to guess. Your claim that it would take an "attacker with no knowledge of your system" years to find a collision is just plain wrong.
May
21
comment Are random URLs a safe way to protect profile photos?
@basic there are lots of different kinds of uuids and no there's absolutely no reason for the attacker having to know your system for any of those to be vulnerable - particularly not for type 4 UUIDs...
May
21
awarded  Yearling
May
21
awarded  Nice Answer
May
20
comment Are random URLs a safe way to protect profile photos?
@WGroleau It should be pointed out that in that link all the given examples are of systems that are in one way or another broken. None of the broken systems used a large search space combined with a secure random generator. I mean really.. sequential URLs? So I find that less applicable than the given link which shows an inherent flaw in the system (for some uses only) and not just problems with broken implementations. Although it shows that people will try to exploit such a system so better make sure it's sound!
May
19
comment Are random URLs a safe way to protect profile photos?
@owenfi In that case I think we can consider this reasonably safe assuming you use a large enough address space and a secure random algorithm to create the URL.
May
19
awarded  Teacher
May
19
answered Are random URLs a safe way to protect profile photos?
May
10
comment Why do I hear about so many Java insecurities? Are other languages more secure?
@Lekensteyn The Java language specifications demands that implementations detect stack overflows and throw an exception. In C/C++ it's just undefined behavior with all that entails. So to some degree "stack overflows" still works as well there.
Apr
12
comment How to explain Heartbleed without technical terms?
Arguably technical terms in this answer, that are not explained before being used: encryption, library, SSL, network traffic, server load, payload size,.. and that's about a quarter of the explanation in before I got bored. I think people here forget that a large part of the population doesn't know what a "browser" is.
Mar
9
comment How secure is Java's hashCode()?
@Adnan Certainly no crypto expert (and a 256bit key makes the chances of a collision minimal to say the least - works fine for git), but I agree with Ben here: If you don't use the object's hash/key/whatever for authorization, why not just use a simple counter? Guaranteed to be collision free, faster and simpler - also predictable but assuming a correct authentication method that's not harmful.
Mar
3
comment Why can we still crack snapchat photos in 12 lines of Ruby?
@theGreenCabbage Classic example of security of obscurity in any case. If you want the receiver to be able to see the picture, the receiver can make a copy of it. At least if you have full privileges on the phone which really isn't hard to achieve. Heck make the picture fullscreen (no idea about snapchat but I guess they allow that?) and just make a screenshot - no big difference in the result.
Jan
14
awarded  Announcer
Sep
10
comment Deleting a Java Object securely
@Thomas Pornin To nitpick a bit ;) Theoretically one can avoid the GC problems, the "solutions" are just somewhat.. complicated or need a compliant API. #1: ByteBuffer.allocateDirect(). #2: Use an unsafe object to allocate the necessary memory and craft your own char[] or string. #1 obviously only works with an API that would use CharBuffers (ugh) and #2 has more than enough problems (though I've wrote a small app once to win a bet). But in both situations you get memory that is not allocated on the GC heaps and therefore not copied around if you use a stop&copy GC.