597 reputation
18
bio website sebrenauld.co.uk
location Washington, United States
age 25
visits member for 1 year, 3 months
seen Jul 18 at 20:28

Programmer. Physics graduate. Data scraper. Server admin. All this as a hobby!

(If you've liked an answer I've provided, don't forget to check http://blog.rescrape.it/ )


Apr
12
awarded  Yearling
Nov
1
comment Securing REST API for mobile use with OAuth
it's one of those myths, sadly. The myth that encryption is this devious, crazy, computationally expensive thing (which it can be, by the way), which is not helped by non-technical people writing articles confusing encryption and hashing and saying that it is computationally expensive to "decrypt hashes", for instance. All of it is hearsay :-( HTTPS requires one more hop, a couple extra if you're verifying the full CA chain, but very few agents should ever do this.
May
17
comment Do SSD's offer significant performance boost for Scrypt?
if you get to swapping, I was thinking that distributed computing might work out in your favour both in terms of economy/costs and time.
May
17
comment Do SSD's offer significant performance boost for Scrypt?
Thank you for confirming what I thought.
May
17
comment Do SSD's offer significant performance boost for Scrypt?
Correct me if I'm wrong...but when computing a scrypt run, your harddrive is not used? How would a SSD benefit? Just bung in more RAM, the faster the better?
May
17
comment How secure is using CRAM-MD5 for email authentication, when not using an SSL connection?
@Adnan: I will say it again: it is trivial to compute the user's password knowing the secret (which is sent in plaintext) and the response (which is nothing more than MD5(password XOR pad || MD5(password XOR pad2) || secret)). And yes, the attack still applies for SHA-512 but is significantly harder to perform (and akin to brute-force. MD5 flakes this off). I'm trying to find a source that has more than one paragraph on the whole DIGEST-MD5 vs. CRAM-MD5 and how CRAM-MD5 is significantly weak to chosen plaintext attacks.
May
17
comment How secure is using CRAM-MD5 for email authentication, when not using an SSL connection?
@Adnan: I have just mentioned: chosen-plaintext. publib.boulder.ibm.com/infocenter/zos/v1r12/… for more info.
May
17
comment How secure is using CRAM-MD5 for email authentication, when not using an SSL connection?
AJ: pretty much. Pointed that out in my answer - also, you can get free non-extended SSL certs these days. There's really no excuse anymore, it's no longer 2004 when certs were going for $500/year.
May
17
comment How secure is using CRAM-MD5 for email authentication, when not using an SSL connection?
@Adnan: Assuming he's not using SSL (which he isn't), the password is used as the HMAC key. All the rest of the info used in computing the HMAC response are known from previous exchange. Can be brute-forced, and has been brute-forced. Cain even has a module for it.
May
17
comment How secure is using CRAM-MD5 for email authentication, when not using an SSL connection?
AJ: most lambda *nix servers have this issue in order to be able to deal with more than one SASL mechanism. They're, however, all configurable to change this, however (I know this, I patched my own dovecot to check vs. SHA512 hashes).
May
17
answered How secure is using CRAM-MD5 for email authentication, when not using an SSL connection?
May
16
comment Touch Screen Password Guessing by Fingerprint Trace
@Mythio: This depends on the finger of the individual. I have nearly indiscernable traces on my TF300T due to naturally very greasy fingers. However, that's just me. My point was mostly a side point - they could add a couple of multiples in patterns by allowing overlaps.
May
16
comment Touch Screen Password Guessing by Fingerprint Trace
@Luc: I think it would be reduced if the patterns allowed a start and end point to be the same, thus increasing the number of possible patterns per smudge trace from 2 (forward-backward) to 2(N-1). Needless to say...not surprised.
May
15
comment Data needed for why not to load third party JavaScript on web page with credit card form
Let's stop getting ahead of ourselves here. The company considers you a trusted third-party, so it should be trivial. However, you need to audit your employees and make sure they cannot make such changes. That's your job. The attack vector is modification of that JS file by a malicious user - make sure it can't happen.
May
15
comment Data needed for why not to load third party JavaScript on web page with credit card form
It was just an idea. Looks like you don't really have a choice - but you'll need to make sure no-one can rewrite your JS, which involves a hefty amount of security auditing.
May
15
comment Data needed for why not to load third party JavaScript on web page with credit card form
Question. If it's a widget...why not just sandbox it within an iframe? It'll be off-site so the IFRAME won't be able to ping the outside or vice versa.
May
15
comment Unsolicited Password Request from Facebook
Deleted my answer and +1d you.
May
14
comment Wireshark Decode HTTPS Root Certificate
What would be the point of using SSL if it could be circumvented that easily? If you're interested in seeing encryption/decryption at work, however, set up a root CA on a browser of your choice and allocate your own CAs, thus effectively hijacking certificates on your machine. This will allow you to set certificates for random sites as you see fit, which will allow you to see both ends of the system.
May
14
comment CSRF protection with Session Id
@Manishearth: good point. I fixated on a case where it was possible to break out of same-origin (which may be possible when combined with an XSS vuln).
May
14
comment CSRF protection with Session Id
@Manishearth: the main purpose of CSRF is to force a user to go through a form, and thus to indirectly prevent XSS. If anything, using the SID as the hidden input makes your sesion IDs trivial to get - load up a form, write down the input[type="hidden"] value, you have the person's cookie. Another reason to stick to random values.