2,270 reputation
625
bio website N/A
location Canberra, Australia
age 30
visits member for 1 year, 5 months
seen Nov 1 '13 at 5:02

.


Jun
19
awarded  Nice Answer
Feb
6
awarded  Yearling
Mar
26
awarded  Revival
Mar
7
awarded  Enthusiast
Feb
24
awarded  Enlightened
Feb
22
awarded  Enlightened
Feb
22
awarded  Nice Answer
Feb
21
comment How can I tunnel through an SSH server for HTTP(s) requests?
Have a look at wiki.vpslink.com/Instant_SOCKS_Proxy_over_SSH - what you're after is achievable with a SOCKS proxy, the only caveat being that client software (IE/Firefox/Chrome in the case of HTTP/HTTPS) needs to support it and be configured to use it.
Feb
20
reviewed No Action Needed What is the correct way to implement anti-CSRF form tokens?
Feb
20
reviewed No Action Needed What is the correct way to implement anti-CSRF form tokens?
Feb
20
comment Cracking MS-CACHE v2 hashes using GPU
Have a look at my update above - it contains the link for MSCash2 - openwall.info/wiki/john/MSCash2 and a couple of other things I found out.
Feb
20
awarded  Nice Answer
Feb
19
awarded  Good Answer
Feb
17
comment Is this SSO design secure?
We're getting way off topic; maybe worth a second question if you want detailed answers. The quick answer is: 'DNS Poisononing is easier than you think, public wifi plus a cheap device - and cache entries can outlive your connection to a compromised network.'
Feb
17
comment Cracking MS-CACHE v2 hashes using GPU
I've added a section detailing what I found of MSCache2 - as compared to openwall.info/wiki/john/MSCash I don't think it's anywhere near as attackable. You'd have to go in with some prior knowledge of some description.
Feb
17
revised Cracking MS-CACHE v2 hashes using GPU
added 925 characters in body
Feb
17
comment Is this SSO design secure?
A simple method is to find a site that has an open redirect (or set one up yourself; somesite.com/?redirectto=auth.com) and run a DNS poisoning attack of some sort to make somesite look like your site.
Feb
16
comment Is this SSO design secure?
That's really not true - forging the referer is easy, so is forging the query string, but neither matter; because it's not that big a risk to authenticate a user against a service they have access to - just make the token site specific.
Feb
16
comment Is this SSO design secure?
In any scenario where they're making an HTTP request, they can choose to ignore it, they can instruct users to turn it off, etc. (don't underestimate the social engineering aspect) - but just because it's hard to articulate a precise attack doesn't mean that it's hard to exploit. (Also, checking the referer and checking the query string are about as hard as each other - why not just make it work when it's turned off? The principle here is don't trust the client, build your site with that assumption and you'll automatically make it harder to attack.)
Feb
16
comment Is this SSO design secure?
I mean add it to your query string so you're not relying on the browser to send it (in the case where a user has referers turned off, or you're requesting across domains and one is https). x-frame-options:DENY relies on the browser also doing the right thing - there's no reason an attacker can't just ignore it.