At 7/9/16 11:16 AM, MSGhero wrote: Edit: even if not, how do you prevent people from seeing other keys in your code?

You don't. Which is why you never trust the client with this kind of information.

At 7/9/16 12:18 PM, PrettyMuchBryce wrote:

At 7/9/16 11:16 AM, MSGhero wrote: Edit: even if not, how do you prevent people from seeing other keys in your code?

You don't. Which is why you never trust the client with this kind of information.

So like... when I connect to NG's api with my project keys via a swf alone, there aren't 6 Tricks To Prevent People From Seeing Your Keys? Like hosting them externally and downloading the strings or anything like that?

Implemented JWTs recently for an API, found them really clear. For some reason, I can't generate the correct signature for the demo though.

At 7/9/16 11:39 AM, Diki wrote: when the HTML5 game is viewed, the user's info is passed to the HTML5 application via a query string.

Is that how it currently works?

I would have thought it'd be better to never use user credentials after authentication through the login form, just expose a key to the app.

At 7/9/16 01:41 PM, MSGhero wrote: So like... when I connect to NG's api with my project keys via a swf alone, there aren't 6 Tricks To Prevent People From Seeing Your Keys? Like hosting them externally and downloading the strings or anything like that?

If you host them externally and download them to the client, it means that any client can see them so they may as well just be on the client in the first place.

I'm only speculating here, because I don't know for sure. My guess is that the NG API uses your API ID and "encryption" key to identify your application. It can use this to make any public calls to the NG API, but in order to perform user-specific actions such as leaderboard entries and medals it will need some secret from the user which is stored in the user's newgrounds.com cookies (or some similar mechanism).

At 7/9/16 02:01 PM, Sam wrote:

At 7/9/16 11:39 AM, Diki wrote: when the HTML5 game is viewed, the user's info is passed to the HTML5 application via a query string.

Is that how it currently works?

I would have thought it'd be better to never use user credentials after authentication through the login form, just expose a key to the app.

The user info is exposed that way as a convenience for non-multiplayer/online games, so they can show the logged-in-user information on their game or whatever. If someone were to change the query string, it wouldn't affect anything but what that player sees, so changing it wouldn't accomplish anything. But for multiplayer/online HTMl5 games, the info that defines the player/user needs to be sent to your server, and as it is coming from JavaScript it cannot be trusted, regardless of what is being sent.

To authenticate with the API, all you need is the player's username, their session ID, and your secret key; the rest of the passed query string can be ignored because the response from newgrounds.io will contain the same information, which can be trusted. The username needs to be included with the session ID, otherwise someone could just spam session IDs until it matches a valid one and then authenticate as that user, whereas including both the username and session ID makes that significantly more difficult.

edit:

At 7/9/16 02:23 PM, PrettyMuchBryce wrote: I'm only speculating here, because I don't know for sure. My guess is that the NG API uses your API ID and "encryption" key to identify your application. It can use this to make any public calls to the NG API, but in order to perform user-specific actions such as leaderboard entries and medals it will need some secret from the user which is stored in the user's newgrounds.com cookies (or some similar mechanism).

The encryption key is public so it doesn't matter if it is ever known, which is why it can be included in client-side applications. It is only useful for encrypting data, but not decrypting. So, if someone manages to get hold of your encryption key, they could only ever used it to encrypt data, but not decrypt data that has already been encrypted. To decrypt it, they will need a private key, which should, of course, never, ever be exposed.

Incidentally, that is the same way that SSL and, by extension, HTTPS work: one key to encrypt and a different one to decrypt.

At 7/2/16 11:30 PM, MSGhero wrote:

At 7/2/16 10:20 PM, GeoKureli wrote:

cough, MSGHero

I started by adding a small feature that only I needed, then by simplifying some math (think: getting the direction from A to B without doing trig twice), tackled some minor issues that people didn't have time for, completely rewrote the object pool, posting some meta issues, etc etc.

And making the Japanese language work in text fields, more or less: https://github.com/openfl/openfl/pull/1186

At 7/9/16 02:23 PM, PrettyMuchBryce wrote: If you host them externally and download them to the client, it means that any client can see them so they may as well just be on the client in the first place.

I need to give myself a security refresher or something.

Q: let's say the as3crypto algos are all good, and someone translates them to haxe. When haxe does its thing to each target, is there anything that can happen that would render the algos all of a sudden insecure? It's just math to me, and I don't see what bad could happen (temp variables will lose scope, etc).

At 7/9/16 02:51 PM, Diki wrote: The user info is exposed that way as a convenience for non-multiplayer/online games, so they can show the logged-in-user information on their game or whatever. If someone were to change the query string, it wouldn't affect anything but what that player sees, so changing it wouldn't accomplish anything. But for multiplayer/online HTMl5 games, the info that defines the player/user needs to be sent to your server, and as it is coming from JavaScript it cannot be trusted, regardless of what is being sent.

Ahh, I thought by user info you meant credentials. This kind of makes sense though.

<replied about something but ditch this always thought of session IDs as incrementing ints>

The username needs to be included with the session ID, otherwise someone could just spam session IDs until it matches a valid one and then authenticate as that user, whereas including both the username and session ID makes that significantly more difficult.

Why not just increase the length of the session ID? Just as I could spam the ID, I could also spam the username. Surely it can just be seen as a single string if an attacker was randomly generating. In fact, you'd increase the attackers chances marginally because they can check what a valid username consists of and reduce the alphabet for that when generating strings. Also, I think you can expect to reduce the size of the HTTP payload when sending the data if you exclude the username and increase the ID, but again, marginally.

Mostly insignificant but it's fun to think about.

Incidentally, that is the same way that SSL and, by extension, HTTPS work: one key to encrypt and a different one to decrypt.

Asymmetric encryption if anyone wants to do further reading.

Would any of you be interested in a Discord server, by the way? Don't wanna undermine the forums but I think it might be pretty cool.

At 7/9/16 03:59 PM, Sam wrote: Would any of you be interested in a Discord server, by the way? Don't wanna undermine the forums but I think it might be pretty cool.

this is the third time discord has come up in my life today, which is weird because I've never heard of discord until today.

At 7/9/16 03:59 PM, Sam wrote: Would any of you be interested in a Discord server, by the way? Don't wanna undermine the forums but I think it might be pretty cool.

We do have a chat for this forum, though I don't think you can get to it without going through the sticky post.

At 7/9/16 03:16 PM, MSGhero wrote: security

I heard my name.

Q: let's say the as3crypto algos are all good, and someone translates them to haxe. When haxe does its thing to each target, is there anything that can happen that would render the algos all of a sudden insecure? It's just math to me, and I don't see what bad could happen (temp variables will lose scope, etc).

Should be fine, but it would ultimately depend on the algorithm and the implementation. If you're encrypting a file using AES then a malicious program digging into memory will find the key somewhere. It may not know what it's found or where the key is if it's even looking for it, but it's in memory somewhere. Alternatively, if you're using something like DH/RSA then I suppose it's possible the client's private key can be leaked on the network somehow by a bad implementation. It's definitely going to be in memory for at least a good while, though, so I'd honestly be more worried about that than anything else. Any way you look at it, I wouldn't worry much. As long as the implementation follows RFC standards, everything will be fine.

Besides, isn't there a native crypto library implementation for Haxe somewhere anyway? What are you really worried about?

As a side-note on the topic of public/private keys at hand:
The whole thing works just as it sounds. I'll use PGP as a quick example, but the schamtics follows the same any way you look at it.
You create a public/private keypair that are cryptographically sound in one way or another (many specifications for such) such as PGP. You give your public key to as many people as you possibly can and you keep your private key as secure as you possibly can (mine is encrypted with three different algorithms and three different passwords, one of which is randomly generated and I don't even know what it is). The private key is for signing and decryption, and the public key is for verification and encryption. Neither can be used for the other's job.
For example: You sign a file with your private key. The public key can then verify that signature to guarantee that file A) hasn't been tampered with, and B) is from you. You can also sign text and whatnot, but entire files are more impressive :)
Another example: Someone uses your public key to encrypt a file/message to you. You use your private key to decrypt that message. Nobody else but you, with your private key, can decrypt that message.

Public/private keypairs are used in RSA as well, usually granted with a DH-like key exchange algorithm (see my previous post on that + quantum computing earlier) - this is common in the TLS protocol (which is most common with HTTPS)

Less common (but still very common) are public/private keys for, say, RESTful applications. The public key usually encrypts data to the private key in these situations, though in this particular instance (the one in this thread) it seems the private key (on your server's end) is used to sign the message sent to NG's server (the public key) - This most probably is an RSA implementation, but I could be wrong and NG may just have a ton of public keys (one for each user)
(I also could be completely wrong about NG's implementation, I just guessed at it based on your posts)

Edit:
The specifications, by the way, are pretty clear-cut. The biggest mistake I can foresee is not using a CSPRNG when prompted for random numbers (either from your own code or the library you're using). Though I swear to god if I see you use Dual_EC_DRGB I will take your code and bash you over the head with it until you learn >:(

At 7/9/16 10:34 PM, egg82 wrote: Besides, isn't there a native crypto library implementation for Haxe somewhere anyway? What are you really worried about?

Someone had concerns about exploitability in the flixel group, but I figure you all know more than they do about it.

The haxe-defined algos will call the native ones per target if they exist, but otherwise they are reimplemented in haxe and will be transpiled to other languages. They only have a handful in haxe.crypto package, though, not even AES. The only difference between the haxe-defined ones and haxe-crypto is that the haxe ones are as unreadable as possible. The question is, will the transpiled algos be RFC-compliant if the haxe ones are?

Here's what I mean. This is CRC32 that I pulled from haxe (because it's short). Compile, then look at the JS source. I have no idea what 90% of the js is doing, but the rest is just math and temp variables. Right?

At 7/9/16 11:30 PM, MSGhero wrote: Here's what I mean. This is CRC32 that I pulled from haxe (because it's short). Compile, then look at the JS source. I have no idea what 90% of the js is doing, but the rest is just math and temp variables. Right?

JS isn't really my field, but with CRC32 the only thing you should worry about is if the checksum matches. I modified the first line to output a hex string since that's far more reasonable then some weird integer output. I then compared it to an online CRC32 calculator.

I ran:
"test"
"ThisIsAVeryLongString!1!"
"000000"

All three came out the same. It's good as far as results go. As far as my limited JS knowledge goes, everything looks fine. I noticed some calls to "Math." and vaguely remember something about them either being different cross-browser or insecure in some way, but that knowledge is probably outdated at best. It should be fine.

On a slightly unrelated note: I now has two delicious, delicious VPNs :)
One for speed, one for security. Guess which one's which? (I guess it's not a challenge if you look them up, but eh)

Also I think tomorrow I'll look into building a multi-server consensus system for handing out cryptographic keys and keeping track of who has what keys. Sounds like fun!

http://prntscr.com/br0zqg
http://prntscr.com/br0zub

>:(
Yeah, fuck it all, I'm going to bed.

/rant

Yo dawg, I heard you liked wallets. So I got a PayPal wallet for your Coinbase wallet for your BTC wallet for your MitM payment wallet for your NMC wallet.

At 7/10/16 03:07 AM, egg82 wrote: http://prntscr.com/br0zqg
http://prntscr.com/br0zub

Why would you want a .bit TLD? It seems like a good way to make your site unnoticeable(r)

At 7/10/16 08:34 AM, Gimmick wrote: Why would you want a .bit TLD? It seems like a good way to make your site unnoticeable(r)

It would be in addition to the .com and .ninja TLDs I already have. Just something for those who trust a blockchain more than they trust CAs (or just don't trust CAs I guess)

I finally took the intelligent way in and went here: https://dotbit.me
$5/yr is half the cost I'm paying for each of my other TLDs. I'll find some way to live without that money :)

I got verbal authorization to pentest my company's servers a week or so ago (the screenshot I posted before) and although I'm super busy with three jobs I still find time here and there to poke new little holes in their system.

I can't get a shell because their backend is so broken that nobody can actually log into it. I'm having to resort to non-administrative LFI only for now (can't grab the system registry or this would be long-over). I mean, I guess that's one way to keep hackers/pentesters out.

Either way, I'll find a way in sooner or later (I'm going to err on the side of "sooner"). Looks like the machine in question is connected to two internal networks (one starting with 192.x - which looks like a front-facing router - and one starting with 10.x) and one of them (10.x) is connected to multiple other windows servers with a DC (which seems to be hosting a website with exe downloads. Dafaq?). My guess is password reuse will be a thing here (based off past activity), but I'm also pretty sure the rest of the network is super out-of-scope since I keep finding other, unrelated websites on these machines.

New styles?

At 7/13/16 02:49 PM, Sam wrote: New styles?

I like it a lot.

At 7/13/16 02:54 PM, egg82 wrote:

At 7/13/16 02:49 PM, Sam wrote: New styles?

I like it a lot.

Yessss

Slightly unrelated:

I work in a call center now, as you might or might not know.
I got a call yesterday by someone from the south. Our customers call the store numbers and get redirected to us. She was expecting to be talking to the store (most are) so I let her have that illusion. After a while it became obvious I wasn't in the area (not knowing city from the zip code given, etc) and she asked where I was located. After I told her she said "Oh, no wonder you sound Canadian!" - I'll be honest, that's a first.

Earlier today I got a call from a customer asking to change their company info because they were bought out. I noticed the company name was "Sandisk" and she said to change it to "Western Digital" - So, yeah, that's a thing.

First time compiling stock linux kernels with custom security patches. Running this on a test server VM for future deployment on my webservers. Sounds fun!

In the meantime, I'm developing a quick USB keylogger malware in C#, studying how neural nets work for some C# experimentation, and looking more closely at "Consensus" and the different types/implementation of the Paxos Agreement.

http://prntscr.com/bu7pz9

I totally haven't been working on my side project every week like I had planned. I've just played pokemon all day... maybe next week

At 7/13/16 03:56 PM, egg82 wrote: Slightly unrelated:
Earlier today I got a call from a customer asking to change their company info because they were bought out. I noticed the company name was "Sandisk" and she said to change it to "Western Digital" - So, yeah, that's a thing.

Huh. Turns out they did indeed acquire Sandisk in May :\

Edit:

I got verbal authorization to pentest my company's servers a week or so ago (the screenshot I posted before) and although I'm super busy with three jobs I still find time here and there to poke new little holes in their system.

I should hope you got written authorization as well, lest it become a he-said she-said issue.

Few bugs to fix, and then I'll post a demo of my procgen roguelike whatever game this weekend.

At 7/22/16 10:07 AM, MSGhero wrote: Few bugs to fix, and then I'll post a demo of my procgen roguelike whatever game this weekend.

Awesome. I'm looking forward to checking this out.

I got stuck down a rabbit hole with my DHT project over the weekend debugging a socket issue in Go. I wrote a little bit about it here, because I learned some new things as I was trying to figure out what was happening. This is a draft. I still need to clean it up.

http://bryce.is/writing/code/macosx/debugging/udp/sockets/dtruss/dtrace/eaddrinuse/2016/07/17/debugging-udp-sockets-on-mac-os-x.html

At 7/22/16 01:57 PM, PrettyMuchBryce wrote: I got stuck down a rabbit hole with my DHT project over the weekend debugging a socket issue in Go. I wrote a little bit about it here, because I learned some new things as I was trying to figure out what was happening. This is a draft. I still need to clean it up.

http://bryce.is/writing/code/macosx/debugging/udp/sockets/dtruss/dtrace/eaddrinuse/2016/07/17/debugging-udp-sockets-on-mac-os-x.html

I definitely learned something reading that! I remember there was a time when debugging was completely sealed within my own code. It took me a long time to poke around the source of the libraries I was using in order to figure out exactly what was happening. Although systems calls and the kernel still seem like black magic..

I guess one thing I didn't really understand is what the next step was. If

doesn't guarantee that the socket closes right away, what do you do with your unit test then?

At 7/22/16 10:07 AM, MSGhero wrote: Few bugs to fix, and then I'll post a demo of my procgen roguelike whatever game this weekend.

So many new bugs are popping up hahaha....

Testing with multiple enemies now, I realize that I actually need to use a grid-based pathfinder rather than the line of sight waypoints I'm using now. Slightly worried that since enemies aren't TILE_SIZE by TILE_SIZE, I'll have issues actually following the generated path. Or that following the path will look very grid-based.

@PrettyMuchBryce do you have any suggestions for algos? Multiple enemies, one moving target, terrain can change a little, avoid grid-based-looking movement, some paths will be pretty tight fits, enemies can move in any direction (360 degrees). The issue now is that multi-raycasting from 5+ enemies is causing visible stutters, although I only do this once per .1 seconds so the stutters are a bit weird.

*sob* it took me forever to get pathfinding to where it is now