aj-code

In short, it's not. A robust scheme should be secure if the attacker knows the algorithm or not. The secret should not be the algorithm, the secret should be a sufficiently long secret value.

This is a good overview of how hackers actually crack hashes if anyone is interested. https://www.trustedsec.com/june-2016/introduction-gpu-passwo...

The other things to take into account:

Code complexity, quality, and cost of ownership. Rolling your own scheme when mature and well tested code already exists is generally something to be avoided, especially when crypto is involved.

Force multipliers. Your server is probably using a CPU to calculate hashes, while hackers are using at least GPUs and possibly FPGAs or other hardware, which are hugely faster than your CPU. So yes, while you can use any cryptographic hash with enough rounds to make high quality passwords unlikely to be cracked, using a password specific algorithm correctly will greatly reduce the advantage hackers have. This makes more of your user's passwords unlikely to be cracked.

The password hashing algorithm outlined is really not best practise, only 7 rounds and the use of SHA-256 which is a general cryptographic hash, not a password specific one.

The correct answer to password hashing is still mostly "just use bcrypt", or even better, scrypt or argon2. Failing that PBKDF2 with enough rounds is not terrible, if you have to. All of these algorithms should to be tuned to require as much processing power as you can afford.

I'm also a fan of storing another random value somewhere separate from the salt/password hash, which is incorporated into the hashing scheme. You might store the salt/password hash in the database, and the other random value on the application servers. This means if your database is compromised (i.e. though SQL injection), hashes can't be cracked without also compromising an application server.

I think the reality is that this style of attack is difficult enough that it would be something of a last resort, and probably only tried on high value targets. It'd take a long time (you'd probably need 100s of millions of requests) and could be easily noticed.

That said, while it's not instant game over, you don't really want this vulnerability if you can avoid it. Especially in things like authentication libraries.

You'd think so! But that's not what I found, I found the minimum, max, and average were all crap. Even the median wasn't very good compared to the 10th percentile (which I got the idea from for here http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf)

I wrote a tool a while ago for testing network based timing attacks. Getting the measurement right is really hard, just taking the average doesn't generally work while the 10th percentile measurement is much better. I did find PHP fairly hard to exploit though, but I was trying over a network which much more difficult than locally.

The code for the tool (and a presentation pdf) is here if you're interested: https://github.com/aj-code/TimingIntrusionTool5000

Sure is!

It would be possible to use a challenge response authentication scheme (http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...) but just doing things over HTTPS is generally fine.

This has some fairly serious security issues, which is fine for a something not designed to be seriously used (or at all). However, the readme implies you could use this and your files will be safer than with some third party. Which is dangerous, to say the least.

I'll outline a few obvious issues I see:

- No explicit protection against directory traversal attacks (../../etc/passwd type stuff) on upload and download.

- Shell command injection on the file name on upload.

- Naive authentication. - Unsalted, fast hash sent in the URL. - Password stored in clear text server side.

- No transport security (HTTPS).

This is cool as a interesting project to work on, but it should be made clear not to use this for anything just yet.

One of the most useful features of that site used to be that you could tell at a glance which browsers the XSS payload would work on, and which it wouldn't. It hasn't been updated for modern browsers so now you have to test each browser yourself.

A lot of the payloads aren't based on browser "bugs" as such, more just the way browsers loosely interpret mangled HTML, CSS and JavaScript. Newer browsers tend to be stricter on what they'll interpret, especially when it comes to a potential XSS vector. The site doesn't seem to have been updated for anything after IE7 and Firefox 2, but I'm not aware of any better cheat sheets. Anyone got any?