Even though we were on vacations I made a lot of progress. From the Cooper API now we can:
Use another invitation flow: there is an endpoint where we can find the pools that we are invited to, an endpoint to accept invitations, and another one to decline invitations, this way we can make sure that only those who are invited join and that you can also decline invitations.
Disabled sendgrid, we will delete the code that send emails, everything will be done in the app.
Friend requests, now we can have friends, send, accept and decline friend requests.
Login with facebook.
I put a server on Digital Ocean, started using travis for continous integration, everytime we push to the server repository, the app is built and the tests are run, if they pass we can merge, when we create a pull request to master and merge it, the code is deployed automatically to the Digital Ocean Server and restarted.
Now there is an https version of the server on port 3443, altough the http server is still running on 3000, this was because facebook only allows login from an https server. We may need to get a real certificate (I created and signed one by myself and the browser shows a warning).
In this post I’ll be dealing with the topic of Authentication and Authorization, and at the end of this post I’ll provide some examples and summarize some of the currently used solutions.
The difference
First, let’s deal with what both of these concepts refer to and what the difference between them is.
Authentication means verifying who someone is. This is what sign up and log in are for, the first one defines who you are, while the latter is where the authentication lies, in checking your user-id and password to match you with someone in the system; authentication answers the claim this is who I am with a yep, that’s who you are.
Authorization means verifying that someone has permission to perform an action. This refers to a certain user having or gaining access to a resource, this is usually done through the use of different types of user, e.g., Administrator, Anonymous User, etc; authorizations answers hey can I do this? with yep, you can or if it were an english teacher, can you? to which you would simply groan in disgust at this attempt at comedy.
Tokens
One common way to handle both these processes is through the use of tokens. A token is a series of characters, usually encoded, that represent both to whom the token belongs—to which account it is linked—and what type of access this token has.
An implementation of tokens that I’ve used is JWT (JSON Web Token).JWT consists in three parts: header, payload, and signature. The first two are all base64 encoded and separated by a dot (.), the signature is a bit different, it consists in the following:
The signature part of a JWT consists in taking concatenation of the previous parts, both base64 encoded and separated by a dot, and encrypting and signing it with a SECRET key. As you may have guessed, JWT isn’t supposed to protect your payload from eavesdroppers, what it does is prove that a JWT was emitted by an entity within the system, because of that SECRET key that’s used to sign the signature part of the JWT. Because JWT still exposes user data, it is advised to not include something confidential inside them, what you may include in a JWT is:
Who this token represents—subject claim, user.
Who issued this JWT—issuer claim, client application.
Who this JWT is meant for—audience claim, the server that’s meant to read it.
Up to when the token is valid—expires claim, the Unix Epochup to which the JWT is valid, or, just if issued at is also provided, the time, in seconds, during which it is valid.
When this token was issued—issued at claim, the Unix Epoch.
Custom claims that don’t compromise confidential information, like level of access this token has.
JWTs should be used when a secure connection can be established, so as to not expose this data the public, just in case. As to where to store them I’ll link an article that explores that topic, as its another beast on its own: Where to Store your JWTs – Cookies vs HTML5 Web Storage.
– I swear its me.
References
Jones, M., Bradley, J., Sakimura, N. (December 9th, 2014). JSON Web Token (JWT). On RFC. Retrieved from https://tools.ietf.org/html/rfc7519#section-4.1
Abbot, T. (January 8th, 2016). Where to Store your JWTs – Cookies vs HTML5 Web Storage. On Stormpath. Retrieved from https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
Do I really have to take an exam? But I already know this, can’t you just ask me some questions to test me? These are some of the questions one may be thinking when the topic of IT Certifications comes up. In this post I’ll try to put forth both sides of the argument regarding this topic, I’ll link some resources at the end so you can read more about the topic.
Certifications have shown to work well on industries like engineering, where one can specialize and get certified for various aspects of civil engineering, while another might go for the electrical engineering route. Both can go their merry way getting certified on bridge-building or electrical systems—I think at this point, its evident that my sources of information about these careers are limited to college brochures—because no one would expect an electrical engineer to build a bridge, and he might not be that excited about it, either. But in the software industries, areas do get intertwined, so perhaps certifications aren’t meant for us.
Experience in multiple areas is a plus, it’s an asset that can come in handy in attacking a problem from several angles. For industries like engineering, most things are set in stone, but software is in constant evolution, a certification you might get today may be obsolete come next year; at that rate, is it really worth the time and money required? Some may argue that a certification just means you’re good at passing tests—sidenote: that’s an issue I personally have with the way some companies handle job interviews.
On the other hand. . .
Some employers do look at certifications as a measure of quality and commitment to the area. Certifications serve the purpose of preventing the self-proclaimed expert from ruining your system. As stated in my previous post—about Ethical Hacking—certifications establish and keep track of minimum standards for specialists, and recognizes the individual as credentialed for whatever the topic of the certification may be.
If you’re willing to go through and get certified, here are some of the most requested for IT Security professionals:
To read more on the topic, head over to references.
– Laters, alligat(e)rs.
References
Bolton, D. (July 9th, 2015). 5 Reasons Certifications Aren’t Worth It. On Dice. Retrieved from https://insights.dice.com/2015/07/09/5-reasons-certifications-arent-worth/
Tillman, G. (June 8th, 2010). Why IT certification is a really, really bad idea. On Computer World. Retrieved from https://www.computerworld.com/article/2518765/it-management/why-it-certification-is-a-really–really-bad-idea.html
Tittel, E., Lindros, K. (December 12th, 2017). Best Information Security Certifications 2018. On Tom’s IT Pro. Retrieved from http://www.tomsitpro.com/articles/information-security-certifications,2-205.html
In order to play sounds client-side I researched what libraries could be used to do that without adding that much processing to the browser. And so I came onto p5.Sound, another p5 library, yep. Is there anything that isn’t done by these guys.
p5.Sound allows the browser to preload SoundFilesand then call them to be played wherever in the scope that the sound was stored, since we’re using p5.SceneManagerthese sound files will be preloaded as the first scene loads, so that then whenever they’re called in the code, the SoundFile is ready to play. For background music I’ll be looping a song using a SoundLoop.
Next week will be dedicated to this coding and sound-searching.
This week on It’s not raining, it’s still, in fact, not raining. Me and Barro are going to work on adding some kind of sound effects to the game, as well as background music. It’s time to look for CC Licensed music.
Music by Thatgirlwhoreads on Flickr under a CC License
This past week we worked on generating more ideas and features for the project, oh the struggle of not having a client. And so we’re going to add sound, more types of enemies and trying to convince Gerardo, our PM, that sprites will simply ruin the experience. Maybe we can’t win every battle, but we’ll surely come out of this victorious.
Onwards by Juan Castillo on Flickr under a CC License.
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.
