This time I don’t know what else to do. And I can’t think of any ideas like last week when I did the new enemy.
Gerardo asked me to change the size of the texts in level 1. So I plan to do that. But I mean, that will take me less than 5 minutes to get all the texts to look nice.
I guess I can make some updates to the database. I realized that the level where I implemented the new enemy didn’t make it properly to the DB. So I will get my hand into that.
So this week I worked in the addition of a new enemy. This enemy is immortal, or at least to our knowledge, it is immune to bullets. This enemy is yellow (As if it was a shield), and those are the only visual differences in of the enemy. Obviously if it can’t be destroyed, it won’t give any points and thus it won’t display any text on hit.
And I would love to show here a little GIF of the enemy, but there are some sound issues that don’t let the game load (Not even an specific level). And I’m not blaming anyone, the issue only appears until devices pulled the repository, not before making the push.
My teammates worked this week in the sound system (Using p5.play, please check our README to see every framework we are using). They also worked regarding the implementation of new walls and objects (I helped a little bit on regarding the Mongoose level schema).
Okay okay… Now I don’t have an excuse… If you haven’t noticed, I missed a complete week. Week 10. Why? I could tell you many excuses, but those wouldn’t be completely true. What really happened is that I didn’t plan a moment to write both blogs and neither I dedicated a lot of my time to the project. That is the truth. Now I will tell you that the reason for my reduced interest in the projects that I had another pair of projects to dedicate my urgent attention. And then our one-week break made thing worse, making me forget completely about the work I was missing.
But that will change this week. I will finally implement the new enemy. I will try to touch as little as much as possible the code that my partners have made. As they have mostly dedicated the front-end and the game itself, and I have been working only in the back-end and testing.
If I can make it work changing the level JSON data, would be nice.
After the last security class, when we all did the Last Pass Challenge (Where I did so… so bad), I started to change an generate a lot of passwords (Like 40 as of now) and activated 2-factor authentication on most of the sites where I could. I don’t know why I did this until now, and not when we talked about this topic in class.
I knew what the 2-factor authentication did, but I didn’t know how. So after some reading (Links below) I finally got around all the concepts.
2 Factor Authentication (2FA) is just a layer of Multi-Factor Authentication (MFA)
2FA works even if the device isn’t connected to the internet. Not for SMS 2FA.
It’s very secure, but as everything, it has some weak components.
This makes 2FA a failed attempt to create a silver bullet for security.
Let’s start with the concept of 2FA just being a layer. What layer? Of how many? Why do we have that layer only? I want more of those!
Okay, so the point of the verification is to tell the service that you are who you say you are. That is why we have passwords. And passwords are things we know, and the knowledge factors are the first and basic layer of credentials in an MFA.
The second layer of credentials are the possession factors, which are the things that the user has, like a phone, an ID or tokens. This is the layer where 2FA is based upon.
The last big layer is the third one. It’s called inherence factors. These factors are the things that the user is. Usually, we are talking about biometrics here, but there are ways to measure behaviors and patterns of a user (Behavioral biometrics) such the way they walk, the way the type or talk. This layer is less used because it depends on hardware and it might increment complexity and costs.
There are two more, far simpler layers, that are only used in heavy security demanding systems. Location and time are these layers. This means the location of which the user is trying to access the service and the time might be taken into account to verify you.
And now: Whow do they manage to make 2FA app’s, such as Google Authenticator, work even if the app is completely disconnected from the WEB?
First. I’m going to explain to you two types of One Time Passcode (OTP): HMAC-based OTP (HOTP) and Time-based OTP (TOTP). Both of these are used to generate the numbers that you see in Google Authenticator App, and both use HMACs in the process.
The first method, HOTP, (The inefficient one), takes the secret key the sever gave to you when the account was created or the 2FA service was activated, and a counter as the message for the HMAC function. The counter represents the number of times an OTP was generated. So when I try to login to a site for the nth time (The server must know how many times have I used an OTP. It also knows the secret and has the same HMAC), I also generate the nth code in my app. And this works as long the server and the app have fully synched counters. The server even usually checks from n to n+x values of the counter to see if, by any case, the mobile app has gotten out of sync. In case the app’s counter is ahead, the server can know at which value the app is currently in, but only if it’s in the x-range, and the problem is that the user can get so ahead from the server that it can’t get in sync.
The second method, TOPT (The popular one), also uses an HMAC function and the secret key. But instead of a counter, it uses 30 seconds intervals of UNIX time; It uses floor(Unix-time() / 30) to get to the nearest second. The server and the user are usually just some seconds out of sync, so the server can just check for the previous and following values of the HMAC function to see if that is the code that the user is typing.
Both methods generated a hashed message. Then, both the server and the client slice and apply some modulos to finally generate the code. The user sends the generated message, and the server compares it to the set of messages it generated (In case the user is out of sync), and if the service is using HOTP, it also increments the counter on success.
And because both devices have everything they need to generate the adequate code for that specific moment, they don’t need to be connected.
But is this secure enough?
Well… It depends… This method is as secure as it’s weakest component.
In case that the 2FA isn’t done using an app, but instead uses 2FA-SMS (The server generates a code, it sends it to the user, the user types it in), the integrity of 2FA can be easily compromised by intercepting or redirecting messages.
There are some sites where the account-recovery is badly implemented and can let the hijacker get around the necessity of introducing the 2FA code.
The database where the user keys are stored can also get hacked. With this knowledge, along with the hash and a clock you could, in theory, generate the security code.
Maybe I will post something more regarding this and my current Last Pass experience (I think that there are only some few sites missing!).
My team came up with several ideas and changes. But what I think it’s the most important is that we are going to -finally- introduce proper sprites and sounds to the game. The idea of different surfaces (Like some slippery and bouncy ones) that would affect (And force us to develop) a more complex set of phisycs.
Well, at least I suggested a new issue for the project (new issue) that I will be implementing. That is a new enemy that can’t be killed when shooting at it. This will enable us to develop more levels where we don’t need to care about the gameplay getting to easy if the gun is spammed.
And I need to update the code documentation and the README!
And that’s basically it. We don’t have anything more to do but to prepare for Friday’s presentation. I will publish at the end of the week what we plan to do the next week.
The summary of the last to weeks is the following:
I made some bugfixes regarding the code I was working the past weeks. Some of the scripts were heavily bugged, especially the ones regarding level setting and getting to and from the database.
Realize that I have to update part of the documentation. That I didn’t do.
Realize as a team that we need more objectives to our project. Because, as it is, we kinda have done everything. So that is what we are going to do this week.
This week I worked in getting a level development aid. And I think I did a nice work.
Basically it’s a mocha/chai script, that connects to the testing database and uploads the json file of the level, and if any modification it’s required, it reuploads it. If you refresh the level.
I worked also in the development of a third level using this aid. I think I did a nice level, it’s only missing approval of the rest of my partners before uploading it.
I’m going to be working in the design of a third level. I’m so bad when I play the game that I hope I won’t make anything very difficult or very easy, because it’s possible I won’t be able to pass it alright.
This is the responsibility this week that I’m excited for. I’m going to develop an enviroment where the level designer can test its level without needing to upload the level to the server, and the removing it and so.
