This is a fun idea George. :) I would be down to contribute a bit.

I recently created a project skeleton for TypeScript which includes everything needed for game dev: https://github.com/prettymuchbryce/typescript-gamedev-template

It would be easy to adapt for plain old javascript.

At 9/21/16 04:02 PM, Diki wrote: It's not a matter of being able to confirm the validity of the password. The problem is that it would make it easy to figure out what the password is. One significant problem is that the encryption key (i.e. the password) cannot be salted when used that way and is therefore susceptible to rainbow table attacks. Encryption/decryption is also designed to be fast, whereas hashing algorithms intended for passwords and other secure data are comparatively slow; them being faster means the password can be brute forced faster.

Bcrypt is nice. Scrypt is nicer.
Salt is delicious.
Your password is weak. Your ability to detect a MitM attack is weaker.
You're probably storing passwords incorrectly.
Do we really need yet-another-login-form?

Alright so I spent some time creating a skeleton project in javascript that we could use

Here it is: https://github.com/prettymuchbryce/reglounge
Pushing to master will automatically trigger a build to the github pages here: https://prettymuchbryce.github.io/reglounge/

I just added some faces spinning around in circles which someone should delete and replace with the first real commit. Maybe a character or a tilemap for the top-down game ?

Anyone who is interested LMK your github account so I can add you all as an admin to the repo

At 9/22/16 12:36 AM, PrettyMuchBryce wrote: Alright so I spent some time creating a skeleton project in javascript that we could use

Here it is: https://github.com/prettymuchbryce/reglounge
Pushing to master will automatically trigger a build to the github pages here: https://prettymuchbryce.github.io/reglounge/

Awesome!

I just added some faces spinning around in circles which someone should delete and replace with the first real commit. Maybe a character or a tilemap for the top-down game ?

What should the restrictions be? The basic idea I was going for was that someone has to add 1 "improvement" within some sort of boundary, before it's passed on. It could be a time limit, commit limit (total line changes, or just the number of commits), but I'm keen on the idea of keeping the iterations small, in an effort for more handoffs, and as an exercise in "more bang for your buck" simplistic game design. My vote is for a time limit (1 day... 2?). Let me know what you guys think.

other ideas:
- no removing other people features
- Ok, I can't think of others

Anyone who is interested LMK your github account so I can add you all as an admin to the repo

GeoKureli

After days of work, I still haven't managed to completely solve this problem. Basically, try doing like I did on the image.
The right bottom corner of the player's rectangle collides with left upper corner of a tile. Both collisions happen at t=0, and I have no idea, how to select the one, that must be resolved.
If I select to always resolve by y, I get this. If I select to always resolve by x, it can get randomly stuck when moving across the floor, if I select to resolve neither, it wont be possible to jump on that floating platform, cause it will just fall through it.

I'd really appreciate your help.
http://www.newgrounds.com/dump/item/c254e1c2055b4099eecd381161a7c1d4

At 9/22/16 12:59 AM, GeoKureli wrote: What should the restrictions be? The basic idea I was going for was that someone has to add 1 "improvement" within some sort of boundary, before it's passed on. It could be a time limit, commit limit (total line changes, or just the number of commits), but I'm keen on the idea of keeping the iterations small, in an effort for more handoffs, and as an exercise in "more bang for your buck" simplistic game design. My vote is for a time limit (1 day... 2?). Let me know what you guys think.

The only thing I don't like about the time limit is it feels like you kind of have to sign up for a slot and wait in line behind everyone else. I like the idea of anyone can fork/make a pull request anytime and the admins just accept these commits like that if they're following the rules.

At 9/22/16 06:53 AM, SkyFire2008 wrote: If I select to always resolve by y, I get this. If I select to always resolve by x, it can get randomly stuck when moving across the floor, if I select to resolve neither, it wont be possible to jump on that floating platform, cause it will just fall through it.

Still seems like an issue from trying to resolve overlaps, rather than prevent them.

At 9/22/16 04:50 PM, OmarShehata wrote: The only thing I don't like about the time limit is it feels like you kind of have to sign up for a slot and wait in line behind everyone else. I like the idea of anyone can fork/make a pull request anytime and the admins just accept these commits like that if they're following the rules.

yeah, sounds like a set time frame would bottleneck a lot more. A queue of commits is more free flowing than waiting in line. Perhaps the hot-potato aspect isn't as important as the quick, carefree collaboration, and small prototyping.

At 9/22/16 05:28 PM, GeoKureli wrote: Still seems like an issue from trying to resolve overlaps, rather than prevent them.

Not really, when starting to move, the player rectangle is against the wall, so all collisions happen at t=0, since the distance to the wall is zero.

At 9/22/16 05:57 PM, SkyFire2008 wrote:

At 9/22/16 05:28 PM, GeoKureli wrote: Still seems like an issue from trying to resolve overlaps, rather than prevent them.

Not really, when starting to move, the player rectangle is against the wall, so all collisions happen at t=0, since the distance to the wall is zero.

so the resolution is ending with it embedded in the wall slightly? sounds like it should end up just outside, instead.
EDIT: or are you saying the bottom collision with the tile below is t=0 just as the right collision is t=0... that makes more sense, I'll think about it more

At 9/22/16 06:05 PM, GeoKureli wrote: EDIT: or are you saying the bottom collision with the tile below is t=0 just as the right collision is t=0... that makes more sense, I'll think about it more

Yes, that's exactly what I'm talking about.

At 9/22/16 05:28 PM, GeoKureli wrote:

At 9/22/16 04:50 PM, OmarShehata wrote: The only thing I don't like about the time limit is it feels like you kind of have to sign up for a slot and wait in line behind everyone else. I like the idea of anyone can fork/make a pull request anytime and the admins just accept these commits like that if they're following the rules.

yeah, sounds like a set time frame would bottleneck a lot more. A queue of commits is more free flowing than waiting in line. Perhaps the hot-potato aspect isn't as important as the quick, carefree collaboration, and small prototyping.

On the other, queueing up PRs means that they were added without knowing what may have been added in the mean-time. It might be better to force them to react/acknowledge to the most recent changes

This tweet is the best.

I don't think we should worry too much about overly focusing on the rules. I think if we keep the spirit of small, focused changes, and passing the code around then we will be in good shape. We can always adjust the rules if needed later on. It will be fun to see this change over time.

So who will have the honor of making the first change ? :D

At 9/24/16 01:47 AM, PrettyMuchBryce wrote: So who will have the honor of making the first change ? :D

I'll add some simple movement in the morning

At 9/21/16 04:02 PM, Diki wrote:

At 9/21/16 10:33 AM, Gimmick wrote: I don't understand. Isn't verifying that the file contents (after decryption) proof that the password's correct?

It's not a matter of being able to confirm the validity of the password. The problem is that it would make it easy to figure out what the password is. One significant problem is that the encryption key (i.e. the password) cannot be salted when used that way and is therefore susceptible to rainbow table attacks. Encryption/decryption is also designed to be fast, whereas hashing algorithms intended for passwords and other secure data are comparatively slow; them being faster means the password can be brute forced faster.

Why can't it be salted? And what about something like scrambling the file if login fails after a given number of attempts - would that be more helpful or harmful to the user?

At 9/21/16 10:33 AM, Gimmick wrote: Hm. Zip files seem to be insecure regarding the file contents; is this a problem, though? (Supposing the files within are replaced with unencrypted ones; won't trying to decrypt it result in garbage?).

Probably.

But if the password were figured out using one of the methods I described above, an attacker could replace the files with malicious software (e.g. adware, trojan horses, viruses, keyloggers) that was encrypted with the password and will then be successfully decrypted.

Well assuming that, say, a text file is to be read - how would it cause an issue with an executable file being run? It wouldn't be handled natively, so why would there be a problem with that (or is there something I'm forgetting)?

At 9/21/16 10:33 AM, Gimmick wrote: If so, are there any alternative solutions, in that case?
[...]
(* maybe, maybe not. Depends on whether I'm nailed to the post regarding the requirements or not)

What exactly is the reason you're looking to create this? Are you doing this for fun or is this work for a client who is setting bizarre requirements?

For fun, although in the end I do have to submit something related to what I'd initially specified. (It's a bit embarrassing, I'll add)

At 9/24/16 07:30 AM, Gimmick wrote: Why can't it be salted? And what about something like scrambling the file if login fails after a given number of attempts - would that be more helpful or harmful to the user?

When creating any security environment or application, you need to ask yourself two very important questions:
1. Who is your intended audience?
2. Who exactly are you defending against?

Keep those two questions in mind, always. Avoid feature creep and don't try to defend against everything and everyone.
Remember: Keep It Simple, Stupid.

At 9/24/16 07:30 AM, Gimmick wrote: Why can't it be salted?

Because salts need to be stored in plaintext, or in a manner than can be reverted to plaintext, for them to be useful.

The most common way they are used is with hashes, where a randomly generated salt is included in the password before hashing, and then added on to the resulting hash after the fact—usually at the beginning or end of the hash, but always in a known place—and that is what ends up being stored. Then in order to determine if a given password is valid, the hash and salt combination are taken, the salt is copied from it and then added on to the password which is then hashed; if the resulting hashes are the same, the password is valid.

The only possible way you could salt a password that is used as an encryption key would be to generate the salt and then add it onto the password and use that as the key. As that would change the key, and you've know good way of storing the salt in that manner, you would effectively just be changing the user's password from what they desired; they would have to both be told what their salt is and to memorise what their requested password was changed into.

Doing that would technically prevent rainbow table attacks, but it would only do so at the cost of the user's experience: they can't actually pick their password; they can only pick something and then have it changed slightly, likely much to their umbrage.

At 9/24/16 07:30 AM, Gimmick wrote: Well assuming that, say, a text file is to be read - how would it cause an issue with an executable file being run? It wouldn't be handled natively, so why would there be a problem with that (or is there something I'm forgetting)?

That would depend on what is reading the text file and how.

If they were to receive the files and then muck around them as they see fit, then an attacker could replace a text file with an executable that has been given a customised icon that looks identical to a text file's. Most people will be using Windows, and by default Windows hides known file extensions, and as both TXT and EXE files are known, neither will have the extension shown unless that feature is disabled. So if the attacker picks one of the more common icons for text files that is most likely to be used by a given user, and the user did not disable that feature, they will attempt to run the executable thinking they are opening a text file. At that point, about the only protection they would is Windows's UAC or some form of anti-virus.

At 9/24/16 02:34 PM, Diki wrote:

At 9/24/16 07:30 AM, Gimmick wrote: Why can't it be salted?

Because salts need to be stored in plaintext, or in a manner than can be reverted to plaintext, for them to be useful.

The most common way they are used is with hashes, where a randomly generated salt is included in the password before hashing, and then added on to the resulting hash after the fact [...]
The only possible way you could salt a password that is used as an encryption key would be to generate the salt and then add it onto the password and use that as the key.

What about a constant salt that's hidden from the user (hardcoded into the application)? Assuming that the likelihood that someone would decompile the application to find out the constant, would it be more secure (or does the assumption not hold in practice)?

Alternatively, generating a salt based on the user's current phone data (specs, name, account w/e) would make it constant but different for each phone, but that would just end up locking them into that phone and preventing them from logging in elsewhere.

At 9/24/16 07:30 AM, Gimmick wrote: Well assuming that, say, a text file is to be read - how would it cause an issue with an executable file being run? It wouldn't be handled natively, so why would there be a problem with that (or is there something I'm forgetting)?

That would depend on what is reading the text file and how.

Well in this case the data is hidden from the user - only the application has (as good as) read access, and the user won't be able to run it. Assuming they get access to the zip file and extract the contents, sure. However, for normal functioning it can be assumed that only the application will read the contents of the file. That shouldn't have any risk, right?

At 9/24/16 03:18 AM, GeoKureli wrote:

At 9/24/16 01:47 AM, PrettyMuchBryce wrote: So who will have the honor of making the first change ? :D

I'll add some simple movement in the morning

Gonna be honest, I've never coded JS in my life. I understand the code, I'm pretty sure I can make the changes, but I downloaded the repo and can't get it working. I downloaded pixi.js as well but I have no clue how to link them in IntelliJ (which I just started using). Help would be appreciated

This makes twice in a week we've seen the largest DDoSes ever recorded.. By a landslide.

A couple days ago, Brian Krebs got a massive 620GB DDoS which broke the previous record of.. Like.. 200 I think.
Earlier today Ovh got hit with a 1156Gbps DDoS.

What in the actual fuck is going on? Who in the hell has THAT much power? Why haven't we stopped them yet? Where's the C&Cs for this operation?

I assume this has something to do with the new fiber lines being put down all over the U.S.
Maybe I'm wrong, though.

I know is SOUNDS conceded thinking only the U.S. is involved, but considering the recent fiber being put down + the fact that we're the most targeted country in the world..

Edit: Oh, yeah, this explains some things. I always knew IoT would be the death of us all.

At 9/25/16 12:20 AM, GeoKureli wrote: Gonna be honest, I've never coded JS in my life. I understand the code, I'm pretty sure I can make the changes, but I downloaded the repo and can't get it working. I downloaded pixi.js as well but I have no clue how to link them in IntelliJ (which I just started using). Help would be appreciated

Ah ok. No worries. Do you have node.js installed on your machine? It's all you should need outside of the project itself. I can add more context in the README as well.

https://nodejs.org/en/download/

Once you have node installed, you can use npm to install the project dependencies as outlined in the usage section of the README. Let me know if you still have issues.

As an aside Javascript is general doesn't have great support in IDEs outside of linting and syntax as it is an interpreted language. You shouldn't need to link anything with your IDE. Think of it more as just a text editor, although if you can install a plugin to enforce the StandardJS linting rules then that would help a bit.

Is that helpful ?

At 9/25/16 03:21 PM, PrettyMuchBryce wrote:

At 9/25/16 12:20 AM, GeoKureli wrote: Gonna be honest, I've never coded JS in my life. I understand the code, I'm pretty sure I can make the changes, but I downloaded the repo and can't get it working. I downloaded pixi.js as well but I have no clue how to link them in IntelliJ (which I just started using). Help would be appreciated

Ah ok. No worries. Do you have node.js installed on your machine? It's all you should need outside of the project itself. I can add more context in the README as well.

https://nodejs.org/en/download/

Once you have node installed, you can use npm to install the project dependencies as outlined in the usage section of the README. Let me know if you still have issues.

As an aside Javascript is general doesn't have great support in IDEs outside of linting and syntax as it is an interpreted language. You shouldn't need to link anything with your IDE. Think of it more as just a text editor, although if you can install a plugin to enforce the StandardJS linting rules then that would help a bit.

Is that helpful ?

Greatly! There's a bit more though. had to install the node.js plugin to intellij and hook it to my project for it to recognize things like require(). however I'm still gettting issues like

along with a blank white page

At 9/25/16 06:06 PM, GeoKureli wrote: file:///C:/Users/Yeehaw%20McKickass

Wow

Edit: does the %20 mess things up?

At 9/25/16 06:39 PM, MSGhero wrote:

At 9/25/16 06:06 PM, GeoKureli wrote: file:///C:/Users/Yeehaw%20McKickass

Wow

Edit: does the %20 mess things up?

Off the top of my head: Do you have a local web server running? Shouldn't you be accessing it via localhost:8000 or some port, as opposed to opening the html file directly in your browser?

Try running `npm start`. It will start up the local server on http://127.0.0.1:8080.

You may have to first run `npm install -g http-server`. I will add that to the README.

At 9/25/16 06:39 PM, MSGhero wrote: Edit: does the %20 mess things up?

%20 is a url-encoded space character ;)

At 9/25/16 07:55 PM, egg82 wrote:

At 9/25/16 06:39 PM, MSGhero wrote: Edit: does the %20 mess things up?

%20 is a url-encoded space character ;)

I meant does it need to be unencoded to work properly as a file path

At 9/25/16 08:25 PM, MSGhero wrote: I meant does it need to be unencoded to work properly as a file path

Depends. Most languages use the URL "file://" to load local files because Windows likes things better that way and makes it easy to use. In which case, yes it does.

Real passwords currently in use at my workplace.
Still running a few more lists before I finally give up on the last 10 that I have yet to break.

So I fixed the collision problem I had.
The key was to check collision by X and Y axes separately. Sure, this is not as accurate, but it works.

New version