What are you working on? January 2012

[acpm]

[QUOTE=swift and shift;34425973]crack it: 9641283b87012ba0a51d58ff26fefab5

[editline]28th January 2012[/editline]

100,000 round MD5[/QUOTE]

this was such a quality post, that im going to buy you gold member with your own money, enjoy being a shitlord among shitizens

[supersnail11]

[QUOTE=grlira;34426035]Doing 100,000 rounds is just introducing a work factor. A scalable work factor is still a better idea because it allows you to keep up with increases in computing power.

Still, a correction to what I said: what I meant by SHA/md5 not being safe is that a single calculation (or 10, or 20) is not safe.[/QUOTE]

What do you recommend instead?

[grlira]

[QUOTE=supersnail11;34426150]What do you recommend instead?[/QUOTE]

bcrypt, for example. It's scalable, it has built in salts and there's no known vulnerabilities.

[acpm]

[QUOTE=synthiac;34426210]oh my god what have you done[/QUOTE]

increasing the quality of being a gold member by making him one obviously

[swift and shift]

[QUOTE=grlira;34426227]bcrypt, for example. It's scalable, it has built in salts and there's no known vulnerabilities.[/QUOTE]

bcrypt has no advantages over just looping another hash function

[zenby]

[QUOTE=amcfaggot;34426235]increasing the quality of being a gold member by making him one obviously[/QUOTE]

Hooray

[grlira]

[QUOTE=swift and shift;34426308]bcrypt has no advantages over just looping another hash function[/QUOTE]

Actually, it does. Bcrypt is much harder to implement efficiently on a GPU, compared to, for example SHA256. On FPGA, however, it's a whole different case and bcrypt is pretty much equivalent to another hasing function with a work factor. Still, the point holds.

Related source: [url]http://security.stackexchange.com/a/6415[/url]

[Wyzard]

[QUOTE=grlira;34425926]SHA, md5 or any other general purpose cryptographic hash functions are [b]NOT[/b] safe. They are easy to crack. Any of them.[/QUOTE]
This is a misleading thing to say. A [url=https://en.wikipedia.org/wiki/Preimage_attack]preimage attack[/url] against MD5 or SHA1 is far from feasible, even with all the computing power in the world at your disposal. [i]In the specific case[/i] where you know that the hash represents a password — as opposed to something like the contents of a file — you may have a realistic chance of performing a successful brute-force attack because you can focus on strings that are likely to be chosen as passwords: relatively short, mostly letters with some numbers and punctuation. But at that point you're not really attacking the hash function, you're just guessing the password directly.

Choice of hash functions aside, passwords that are short enough for people to remember are also short enough for a computer to guess by brute force. [i]That's[/i] why you need to add some sort of "work factor" to whatever hash function you use. But as long as you include a suitable work factor, MD5 or SHA1 are no less safe than something like bcrypt. (bcrypt just happens to have a work factor built in.)

Don't label a good hash function as "unsafe" and "easy to crack" just because naïve usage in one particular use-case yields less than ideal security.

[editline]28th January 2012[/editline]

[QUOTE=grlira;34426403]Actually, it does. Bcrypt is much harder to implement efficiently on a GPU, compared to, for example SHA256.[/QUOTE]
...which means a single round of bcrypt runs slower than a single round of SHA256. But you can bring SHA256 down to bcrypt's speed by iterating it.

[grlira]

[QUOTE=Wyzard;34426544]This is a misleading thing to say. A [url=https://en.wikipedia.org/wiki/Preimage_attack]preimage attack[/url] against MD5 or SHA1 is far from feasible, even with all the computing power in the world at your disposal.[/QUOTE]
I agree with you and I've changed the sentence in the original post.

[QUOTE=Wyzard;34426544][i]In the specific case[/i] where you know that the hash represents a password[/QUOTE]
Which is exactly the topic at hand.

[QUOTE=Wyzard;34426544]
— as opposed to something like the contents of a file — you may have a realistic chance of performing a successful brute-force attack because you can focus on strings that are likely to be chosen as passwords: relatively short, mostly letters with some numbers and punctuation. But at that point you're not really attacking the hash function, you're just guessing the password directly.
[/QUOTE]
Any brute force attack is just guessing directly. Of course that if your universe of possible input data is enormous, then that kind of attack is not efficient. But the point is exactly that the universe of possible input data is very limited (like you said, short strings, mostly letters, numbers and punctuation), and thus, with current computing power, a brute force attack is feasible.

[QUOTE=Wyzard;34426544]
Choice of hash functions aside, passwords that are short enough for people to remember are also short enough for a computer to guess by brute force. [i]That's[/i] why you need to add some sort of "work factor" to whatever hash function you use. But as long as you include a suitable work factor, MD5 or SHA1 are no less safe than something like bcrypt. (bcrypt just happens to have a work factor built in.)
[/QUOTE]
I'm sorry if I implied bcrypt is less safe than md5/SHA with work factors. I did not mean that. Bcrypt does , however, have the advantage of having the built in work factor, as well as built-in salting. That doesn't make it safer, but it does force the programmer to follow good practice.

[QUOTE=Wyzard;34426544]
Don't label a good hash function as "unsafe" and "easy to crack" just because naïve usage in one particular use-case yields less than ideal security.
[/QUOTE]
Again, poor choice of words on my part. Fixed.

[acpm]

wow are you nerdes really going to have a hash security discussion over a potential gmodder's facepunch account being at risk

[Wyzard]

TBH, I'm not even really following the discussions about API stuff. I just saw what looked like unfair criticism of some hash functions and thought I'd respond.

[zenby]

I added registers, stacks, and some other stuff
Now I'm attempting functions

[Darwin226]

Good morning. I'll start writing a thread for those algorithmic problems.
I'll post when I have one problem and solution up there and then add 2 more later on.

As for test samples, 2 will be given that you can write by hand and one that has numbers bordering the limit so you can test if your program works correctly.
I don't plan on making an evaluator for more samples but if someone wants to do it then go right ahead.

[editline]28th January 2012[/editline]

Thread is up!
[url]http://www.facepunch.com/threads/1159132?p=34428508[/url]

[simssi]

I was bored, so I made a script loader for Terraria.

clientscript1.cs (in Terraria/scripts/client)

using ScriptLoader;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;

namespace ScriptLoader
{
	public class Script : IClientScript
	{
		public void InitClient(ExtendedTerrariaClient gameClass)
		{
			gameClass.OnPostDraw += Draw;
		}

		public void Draw(ExtendedTerrariaClient sender, GameTime gameTime)
		{
			sender.SpriteBatch.Begin();
			sender.SpriteBatch.DrawString(ExtendedTerrariaClient.fontDeathText, "Hooked :3", new Vector2(30, 30), Color.CornflowerBlue);
			sender.SpriteBatch.End();
		}
	}
}

Result:

[IMG]http://www.1337upload.net/files/s_2012-01-28_13.07.13.png[/IMG]

[@@]

[QUOTE=swift and shift;34423987]md5 is not security.[/QUOTE]

neither is SSL, which is why sending the password every request is a bad thing.. :\

[Hexxeh]

[QUOTE=@@;34428581]neither is SSL, which is why sending the password every request is a bad thing.. :\[/QUOTE]

Okay, describe a plausible attack on an SSL encrypted API request.

[Epic Sandwich]

This may be a stupid question, but if you're sending the username and password hash every single request, surely someone only needs to intercept one request and they can effectively make api calls from your account? Shouldn't you hash a timestamp along with the password or something?

[swift and shift]

[QUOTE=Epic Sandwich;34428811]This may be a stupid question, but if you're sending the username and password hash every single request, surely someone only needs to intercept one request and they can effectively make api calls from your account? Shouldn't you hash a timestamp along with the password or something?[/QUOTE]

hexxeh's using ssl, but otherwise this would be a valid concern

[editline]28th January 2012[/editline]

see:

[QUOTE=swift and shift;34424241]asymmetric encryption + time based token to prevent replay attacks[/QUOTE]

SSL would most certainly have something to prevent replay attacks, although probably not time based since two hosts using SSL negotiate back and forth before communicating

[Hexxeh]

[QUOTE=Epic Sandwich;34428811]This may be a stupid question, but if you're sending the username and password hash every single request, surely someone only needs to intercept one request and they can effectively make api calls from your account? Shouldn't you hash a timestamp along with the password or something?[/QUOTE]

Yeah, that's a valid concern, but as has been rightly said, SSL prevents this.

Sending the userID/username and password hash is effectively unavoidable, one of the side effects of the fact it's a scraping API. If anything, access via the API is more secure than accessing Facepunch normally, since you have the option of SSL.

Also, for anyone thinking that the username/password could be stolen from the query string even with SSL, nope, SSL encrypts the query string too, so that's not going to happen.

Is there anything other than search that's missing from the API? Moderator tools will be in later today all being well.

[@@]

[QUOTE=Hexxeh;34428705]Okay, describe a plausible attack on an SSL encrypted API request.[/QUOTE]

[url]http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091911[/url]
[url]http://www.esecurityplanet.com/browser-security/ssl-beast-exposes-security-risk-.html[/url]

[Hexxeh]

[QUOTE=@@;34428955][url]http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091911[/url]
[url]http://www.esecurityplanet.com/browser-security/ssl-beast-exposes-security-risk-.html[/url][/QUOTE]

Those are browser based attacks. Those don't affect API usage.

[Epic Sandwich]

[QUOTE=Hexxeh;34428839]Also, for anyone thinking that the username/password could be stolen from the query string even with SSL, nope, SSL encrypts the query string too, so that's not going to happen.[/QUOTE]That was my main concern, didn't realise that query strings were encrypted.

[Dlaor-guy]

I was bored again so have a sea of keys.
[img]http://dl.dropbox.com/u/4081391/keysea.gif[/img]
(Alternatively I might make a LIMBO clone and use this as background)

[Hexxeh]

Do we have any Windows Phone developers who'd be interested in writing a Facepunch application? We have Android and iOS covered, that just leaves Windows Phone in terms of major platforms.

[_Undefined]

[QUOTE=Hexxeh;34422748]api.facepun.ch documentation[/QUOTE]

I made my api auto-document with some php Reflection stuff on my api modules.

[img]http://i.imgur.com/cqS1L.png[/img]

[voodooattack]

I like how Wyzard jumps in every now and then, throws some random wisdom at you settling an argument, then disappears again in a puff of smoke like a ninja.

[IMG]http://dl.dropbox.com/u/27714141/ninja-monkey-64-mbp.png[/IMG]

[Wyzard]

Hexxeh, if you're using SSL, why send the password hash instead of the password itself? Does the server store a double hash, and you're only hashing once on the client? (If the hash you send is the same thing that's actually stored on the database, so all the server does is a straight comparison, then someone who steals that database table can log in as any user without needing to figure out the original password at all.)

[editline]28th January 2012[/editline]

[QUOTE=voodooattack;34429495]I like how Wyzard jumps in every now and then, throws some random wisdom at you settling an argument, then disappears again in a puff of smoke like a ninja.[/QUOTE]
Haha, nice image. :-)

I haven't been reading FP as regularly in the past few months, and I'm not working with any game-related or graphics-related programming stuff like most projects in this thread are, which is why I'm mostly lurking.

[Vivelin]

[QUOTE=Hexxeh;34429250]Do we have any Windows Phone developers who'd be interested in writing a Facepunch application? We have Android and iOS covered, that just leaves Windows Phone in terms of major platforms.[/QUOTE]

I might give it a try one time.

[Nigey Nige]

Posting images because fuck your arguments about SSL that I don't understand

[IMG]http://i.imgur.com/wSqac.jpg[/IMG]
[IMG]http://i.imgur.com/WMUHd.jpg[/IMG]

yeaaaaaaaaaaah

[Ashleigh]

So, I implemented LuaJIT into luaserver now and the page generation is back down to about 300 micro seconds (when I made it thread safe, it lost a lot of its speed).

I also added sessions: [url]http://self.arb0c.net/test.lua[/url]

All you have to do is:

[lua]SESSION.TimesSeen = (SESSION.TimesSeen or 0) + 1[/lua]

[url=https://github.com/c0bra61/luaserver/blob/master/src/LuaFuncs.cpp#L495]How cryptographically secure do you think this is?[/url]