Programming - WAYWO - March 2013

[Jookia]

[QUOTE=DoctorSalt;39963623]How do you guys back up your programming projects? Right now I:
Have VS 2012 back it up + Save it to Dropbox + git integration. Considering doing manual backup as well after I lost a project.[/QUOTE]

I back up my entire hard drive on to another.

[OldFusion]

[QUOTE=DoctorSalt;39963623]How do you guys back up your programming projects? Right now I:
Have VS 2012 back it up + Save it to Dropbox + git integration. Considering doing manual backup as well after I lost a project.[/QUOTE]

I have a NAS that's configured in Raid 1, i have it mounted as a drive on my PC, then a simple program to sync when i make a change.

I have some more impressive projects manually backed up on a server that i can mount over a SSH tunnel.

[Darwin226]

Holy crap. I know backups are important but some of this stuff is borderline paranoid.
When will ever uploading to github or something not be enough?

[Jookia]

[QUOTE=Darwin226;39978019]Holy crap. I know backups are important but some of this stuff is borderline paranoid.
When will ever uploading to github or something not be enough?[/QUOTE]

What? I have hundreds of gigabytes of other stuff to back up too, so I figure the simplest way to do it is to just back up everything and worry about it later.

[Darwin226]

[QUOTE=Jookia;39978081]What? I have hundreds of gigabytes of other stuff to back up too, so I figure the simplest way to do it is to just back up everything and worry about it later.[/QUOTE]

Not talking about you. Using 2 HDs with the same data is relatively common. I'm talking about the "I use git, dropbox, manual copies, 2 other harddrives and a remote host hidden under 20 meters of concrete in Alaska to which I have a wireless link"

[Ashleigh]

[QUOTE=Chandler;39956529]Because it makes COBRAa have a conniption [i]everytime I do it[/i].

You forgot to correct a brace by putting it on the newline on line 7. Hope this helps![/QUOTE]

Nah, that's a list initializer, not scope/block deceleration.

[Gulen]

I don't have any screenshots right now, but there isn't much to show, really, but now I've fixed the bug I had where the app would crash when I tried to scroll in the list of stations (I was calling getTag() on a view, and for some reason it was giving me a null back, and I didn't check to see if it was a null or not), so now I've only got a couple of minor things to fix, and then it should be done! (hopefully)

[acpm]

[QUOTE=Lexic;39977857]You want to try running that on MSIE's JScript engine? I don't. Besides, if you're trying to make a standard password system you can't really depend on the client having an acceptably modern and standards compliant browser. People browse the net on a startlingly large variety of things including TVs and actual phone phones (opera mini worst browser.)

I like it, though it does add an entire extra layer of complexity onto the system. For fun, why don't we make the persistent session tokens keyed to your user agent string? :v:[/QUOTE]

Yeah I guess you're right, I briefly forgot about the fact that if the end-user doesn't have JavaScript enabled, a plaintext password should be sent and whatever hashing function is used on the client normally should then be done on the back end instead.

I once saw a simple MD5 of a password sent to the back end of a system before—this occurred through one POST argument—and if the client didn't have JavaScript enabled, it was sent through another. Maybe I'll just do that?

[Tamschi]

[QUOTE=acpm;39977156]Obviously, the only remaining issue that stands is the fact that if a MITM stole the password hash, they'd basically be able to login as the victim and generate a session token until the victim changed their password and had their hash stolen again, and hijacking the session token obviously gives them temporary access as well, but if they get the initial login, then they can preferentially use that instead.[/QUOTE]

That's why you're supposed to use a unique nonce for each login process. It's a one sided zero-knowledge-proof.

[editline]20th March 2013[/editline]

[QUOTE=acpm;39979852]Yeah I guess you're right, I briefly forgot about the fact that if the end-user doesn't have JavaScript enabled, a plaintext password should be sent and whatever hashing function is used on the client normally should then be done on the back end instead.

I once saw a simple MD5 of a password sent to the back end of a system before—this occurred through one POST argument—and if the client didn't have JavaScript enabled, it was sent through another. Maybe I'll just do that?[/QUOTE]

You probably should avoid using md5, at least without a salt.
It's so widespread in urls that it's often possible to just google the hash, not to mention the security issues with that algorithm.

[editline]20th March 2013[/editline]

[QUOTE=Lexic;39977857]I like it, though it does add an entire extra layer of complexity onto the system. For fun, why don't we make the persistent session tokens keyed to your user agent string? :v:[/QUOTE]

And then there's a browser update :v:

[Lexic]

Never use md5 for anything, with or without a salt. Use sha instead.

@Tamschi true, having to log in every time chrome silent updated would be very annoying.

[acpm]

[QUOTE=Tamschi;39980541]That's why you're supposed to use a unique nonce for each login process. It's a one sided zero-knowledge-proof.

[editline]20th March 2013[/editline]

You probably should avoid using md5, at least without a salt.
It's so widespread in urls that it's often possible to just google the hash, not to mention the security issues with that algorithm.

[editline]20th March 2013[/editline]

And then there's a browser update :v:[/QUOTE]

I'm already using bcrypt, so a unique nonce is out of the question... really all of a 100% RFC-compliant digest access authentication system is out of the question, so I better just stop trying to pursue it, since I don't want to drop bcrypt from OpenUser.

I'd use a client salt for the MD5, yeah. It's paper-thin "security," not even that really, but at least it doesn't expose the plaintext pass? I mean... with a MITM it doesn't really matter if the plaintext password is exposed anyway, if you have the hash, you have the "password." It wouldn't protect against a dictionary attack, but if the user is stupid enough to make "qwerty" or something like that their password, it's not my issue.

For a session token, I was thinking about sending back an HMAC-SHA256( ipaddr . passwordHash . datetimeExpiration ), and storing that in a database entry. Attempts to use the session token from a hijacker's IP address would flag the system, and warn the victim to change their password and inform them their computer or Internet connection has been compromised.

[editline]20th March 2013[/editline]

[QUOTE=Lexic;39980654]Never use md5 for anything, with or without a salt. Use sha instead.

@Tamschi true, having to log in every time chrome silent updated would be very annoying.[/QUOTE]

I thought even SHA-2 had exploits?

[Tamschi]

[QUOTE=Lexic;39980654]Never use md5 for anything, with or without a salt. Use sha instead.

@Tamschi true, having to log in every time chrome silent updated would be very annoying.[/QUOTE]

The server could store a bit of info about the session though, like Google does with the access log:

[img]https://dl.dropbox.com/u/5013896/forum/Facepunch/Programming%20WAYWO/3.2013/Google%20Access%20Log.png[/img]

[editline]20th March 2013[/editline]

[QUOTE=acpm;39980741]I'm already using bcrypt, so a unique nonce is out of the question... really all of a 100% RFC-compliant digest access authentication system is out of the question, so I better just stop trying to pursue it, since I don't want to drop bcrypt from OpenUser.[/QUOTE]

Again, this is not mutually exclusive if the user has JavaScript. The nonced-plain-text method is only a limitation of the built-in http access feature.

[QUOTE=acpm;39980741]I thought even SHA-2 had exploits?[/QUOTE]

Yes, but they aren't as bad.

[acpm]

By the way guys, thanks for letting me bounce security ideas off of you. This is the kind of stuff that makes the Programming subforum shine, imo.

[chaz13]

I've been working on a game with elements from X-Com combined with a platform shooter. It's coming along pretty well.

Excuse the shitty video, recorders do not seem to play nicely with me or the game. Enemies appear to disappear for no reason, it cut out halfway through, youtube compression etc.. but you can get the gist! :smile:

[media]http://www.youtube.com/watch?v=s6lxXa2tlA4&hd=1[/media]

[acpm]

Since OpenUser is going for simplicity and essential security, do you think it would still be okay for me to skimp out on logging multiple session locations? My thought was if I just log the one session per-user and implement that IP address association through the session token with a flag if the user is found to be compromised, it would be basically enough for a standard system.

[Tamschi]

[QUOTE=acpm;39980874]Since OpenUser is going for simplicity and essential security, do you think it would still be okay for me to skimp out on logging multiple session locations? My thought was if I just log the one session per-user and implement that IP address association through the session token with a flag if the user is found to be compromised, it would be basically enough for a standard system.[/QUOTE]

It's mostly as secure as the other methods, you just lose protection against offline attacks on the client (stealing the cookie) [del]or automatic reconnect and multiple logins[/del].
Edit: The server could check if the IP changes back and forth, if that is what you mean, but it's not completely secure and you would have to store more than one dataset per connection if you want a trigger more percise than "number of changes in the current hour".

I don't think the session/connection tokens would be too difficult to implement or manage though, you'd essentially do the same thing twice, with the connection tokens exclusive to a session token.

The problematic part about the IP-bound connection tokens is maybe that they don't allow users with constantly changing IP, as the user would have to connect at least twice with the same address.
In practice I don't know of a system that doesn't allow this, though IPv4-backed mobile connection can behave a bit weirdly because the IPs are pooled.

If you implement IP association, make sure you use the right information. Afaik, the default get IP method in PHP returns the presumed client IP, [URL="http://ipfuck.paulds.fr/"]which is easily forged[/URL]. (A lot of websites error with that addon because they don't handle mismatching fields properly. I also had problems with Indie Royale because their anti-piracy scheme is attached to the spoofable IP (my mistake for using it there though).)

I think it would be a good idea to bind the connection to all IP-information available.

[meanwhile]

[QUOTE=chaz13;39980872]-snip-[/QUOTE]

That looks amazing. Will you be submitting it to Greenlight when it is done?

[chaz13]

[QUOTE=NightmareX91;39981109]That looks amazing. Will you be submitting it to Greenlight when it is done?[/QUOTE]

That's my (far in the future) plan. I'm considering a little kickstarter, too, so I can maybe buy a license for a better audio engine/get some artwork redone/hire a composer to help out with the soundtrack. I mean little though, maybe £600 or so.. but even that might be a little ambitious!

Also if anyone's mildly interested, here's two songs that are in the game at the moment. They just placeholders really, but hey ho

[media]http://soundcloud.com/awesomesaucee/spacegame3[/media]

[media]http://soundcloud.com/awesomesaucee/track2[/media]

[Metallics]

[QUOTE=chaz13;39981185]That's my (far in the future) plan. I'm considering a little kickstarter, too, so I can maybe buy a license for a better audio engine/get some artwork redone/hire a composer to help out with the soundtrack. I mean little though, maybe £600 or so.. but even that might be a little ambitious!

Also if anyone's mildly interested, here's two songs that are in the game at the moment. They just placeholders really, but hey ho

[media]http://soundcloud.com/awesomesaucee/spacegame3[/media]

[media]http://soundcloud.com/awesomesaucee/track2[/media][/QUOTE]

It's the kind of thing I know I'd be happy to throw a small donation towards to see finished, looks awesome.

[acpm]

[QUOTE=Tamschi;39981017]It's mostly as secure as the other methods, you just lose protection against offline attacks on the client (stealing the cookie) or automatic reconnect and multiple logins.

I don't think the session/connection tokens would be too difficult to implement or manage though, you'd essentially do the same thing twice, with the connection tokens exclusive to a session token.

The problematic part about the IP-bound connection tokens is maybe that they don't allow users with constantly changing IP, as the user would have to connect at least twice with the same address.
In practice I don't know of a system that doesn't allow this, though IPv4-backed mobile connection can behave a bit weirdly because the IPs are pooled.

If you implement IP association, make sure you use the right information. Afaik, the default get IP method in PHP returns the presumed client IP, [URL="http://ipfuck.paulds.fr/"]which is easily forged[/URL]. (A lot of websites error with that addon because they don't handle mismatching fields properly. I also had problems with Indie Royale because their anti-piracy scheme is attached to the spoofable IP (my mistake for using it there though).)

I think it would be a good idea to bind the connection to all IP-information available.[/QUOTE]

Man, I didn't know about the spoofable IP address bit, and I totally forgot about mobile. Shoot! The funny bit is that the main project that OpenUser was developed for is [url=http://i.imgur.com/NUwFcMX.png]one that I wrote to be compatible with mobile devices.[/url]

[Tamschi]

[QUOTE=acpm;39981357]Man, I didn't know about the spoofable IP address bit, and I totally forgot about mobile. Shoot! The funny bit is that the main project that OpenUser was developed for is [URL="http://i.imgur.com/NUwFcMX.png"]one that I wrote to be compatible with mobile devices.[/URL][/QUOTE]

It could be problematic if the user POSTs something with an invalid token. You could make invalid tokens initiate a new authorization process that retroactively authenticates the request, I think that's possible with HTTP redirects or sending a login script instead.

That would possibly solve the IP-issue and if you don't require the validation to come from the same IP the token was requested for, it would work on extremely volatile endpoints.
The next request would be invalid again, but at least you'd get the data through.

[Hogofwar]

[QUOTE=chaz13;39980872]I've been working on a game with elements from X-Com combined with a platform shooter. It's coming along pretty well.

Excuse the shitty video, recorders do not seem to play nicely with me or the game. Enemies appear to disappear for no reason, it cut out halfway through, youtube compression etc.. but you can get the gist! :smile:

[media]http://www.youtube.com/watch?v=s6lxXa2tlA4&hd=1[/media][/QUOTE]

Dat... lens flare?

[acpm]

[QUOTE=Tamschi;39981724]It could be problematic if the user POSTs something with an invalid token. You could make invalid tokens initiate a new authorization process that retroactively authenticates the request, I think that's possible with HTTP redirects or sending a login script instead.

That would possibly solve the IP-issue and if you don't require the validation to come from the same IP the token was requested for, it would work on extremely volatile endpoints.
The next request would be invalid again, but at least you'd get the data through.[/QUOTE]

Frankly, although I knew that was a possibility, for the sake of user experience, I disregarded it since I think better solutions can exist.

[Tamschi]

[QUOTE=acpm;39982388]Frankly, although I knew that was a possibility, for the sake of user experience, I disregarded it since I think better solutions can exist.[/QUOTE]

Retroactive authentication is the only one where you can prevent losing the form data without running dynamic content on the client in all cases. Otherwise the client will have to run a script that handles authentication and retry or log in manually and then send the form again.

I couldn't test how my mobile internet behaves when I lose connection, but I get a new IP each time I enter or leave the WLAN. My WLAN connection also closes and opens [URL="http://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.html"]depending on activity[/URL] and it's possible that a phone disconnects every time it's not in use, if someone has a crappy data plan and wants to make the most use of it.

The other option would be to use longer sessions that aren't bound to an IP like most websites do, but that is very vulnerable against passive MITM if the connection is insecure.

[chaz13]

[QUOTE=hogofwar;39982064]Dat... lens flare?[/QUOTE]

Not a fan? You can turn it off in the options :smile:

[acpm]

[QUOTE=Tamschi;39982668]Retroactive authentication is the only one where you can prevent losing the form data without running dynamic content on the client in all cases. Otherwise the client will have to run a script that handles authentication and retry or log in manually and then send the form again.

I couldn't test how my mobile internet behaves when I lose connection, but I get a new IP each time I enter or leave the WLAN. My WLAN connection also closes and opens [URL="http://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.html"]depending on activity[/URL] and it's possible that a phone disconnects every time it's not in use, if someone has a crappy data plan and wants to make the most use of it.

The other option would be to use longer sessions that aren't bound to an IP like most websites do, but that is very vulnerable against passive MITM if the connection is insecure.[/QUOTE]

Yeah, unfortunately I think the IP-bound session tokens will have to be another dropped idea. I liked the concept of it until unreliable connections came into play, but if the end-user has to re-authenticate in those situations, then it's not worth it. If you think about what scenarios this would occur in the most, it's probably going to happen primarily in mobile cases, which is the least comfortable situation to be in, since you have to type in your details on a small form factor device, which is annoying as hell to begin with.

[Robber]

I bought an AR Drone last summer but it was pretty disappointed by the wifi range. So I had an idea: what if I duct-taped my old Android on the drone and let it fly autonomously using GPS. If I chose routes on wide open fields the GPS's inaccuracy shouldn't be a problem. I could let the phone send the current position to a webserver every second or so and get the next waypoint from the server. That way I could see where the drone was in Google Maps and click where I want it to fly and the range would only be limited by battery life.

Since the SDK for Android (actually they just open sourced the FreeFlight app) was released like two months ago (and I noticed just now) I thought why not try to actually do that. It took me like 3 days to get the darn thing to compile because it requires a very specific version of the Android NDK, Eclipse and ADT plugins and only compiles on Linux and I'm developing on Windows. After I got it to compile in a Ubuntu VM I copied the .so files in a new Android on Windows and actually got the sample project to compile. That was Monday.
Since then I've been digging through the Java code and I'm actually pleasantly surprised how easy to use the API is. They actual network communication and video stuff is done in a nicely contained service in native code while the rest of the app is Java code including an easy-to-use event based high level API for getting data from the drone and simple methods for controlling it.

Getting the battery status from the drone is as simple as that:
[cpp]
//init code
droneBatteryReceiver = new DroneBatteryChangedReceiver(this);
manager.registerReceiver(droneBatteryReceiver, new IntentFilter(DroneControlService.DRONE_BATTERY_CHANGED_ACTION));

public void onDroneBatteryChanged(final int value) {
Toast.makeText(getApplicationContext(), "Battery percent: " + value, Toast.LENGTH_SHORT);
}[/cpp]

And controlling the drone is even easier:
[cpp]
public void takeOff() {
droneControlService.triggerTakeOff();
}[/cpp]
and flying works in a very similar fashion by just calling setPitch(..), setYaw(..) etc.

Today I managed to take all the backend stuff from the Freeflight app and make a little test app with a single take-off/land button which actually works.
I think the hardest parts are done and I can concentrate on stuff I already have a lot of experience with. I hope I don't lose motivation and I can post a video of my drone flying around my neighborhood in a few weeks.

[redx475]

I'm starting to move my virtual machine to use floats instead of integer numbers because why not, and then I find out that C/C++ doesn't have fixed width floating point typedefs... Time to ignore any platform that uses different sized floats!

[esalaka]

[QUOTE=redx475;39983963]I'm starting to move my virtual machine to use floats instead of integer numbers because why not, and then I find out that C/C++ doesn't have fixed width floating point typedefs... Time to ignore any platform that uses different sized floats![/QUOTE]

It would make no sense to have fixed width floating point typedefs because there is no guarantee that enough hardware would support them to make it reasonable.

[editline]21st March 2013[/editline]

I mean, you can write fairly effective means of handling large integers even beyond the size the processor can handle with single opcodes, but floats pretty much need a FPU or separate float instruction set.

[redx475]

[QUOTE=esalaka;39983998]It would make no sense to have fixed width floating point typedefs because there is no guarantee that enough hardware would support them to make it reasonable.

[editline]21st March 2013[/editline]

I mean, you can write fairly effective means of handling large integers even beyond the size the processor can handle with single opcodes, but floats pretty much need a FPU or separate float instruction set.[/QUOTE]

I understand why there aren't any fixed width floats, but it doesn't make my life any easier. Still, most computers seem to use 32 bit floats, and if I ever encounter otherwise (which I probably will at some point), I'll figure out a way around it. The main reason I need the fixed width is that I'm reading/writing files in binary.