Categories
Uncategorized

Week 7 Blog

I made a recent blog post on keeping passwords safe, so I did a lot more research and creating a few test programs for this purpose. I found that having a user provide the api or application their username and password alone isn’t very safe. Especially if we are storing that password in our database, that immediately puts their information at risk. That is assuming the third party company that will be used for authentication follows much better security measures. Instead of having a customer provide you with the direct credentials, redirecting them to a trusted third party is ideal, such as google. What happens is when a user wants to create an account, we redirect them to google such as OAuth2.0. Then ask the user for permission for say, their email, and general information like name. Once authorized OAuth2.0 returns an authentication token that we can use to further do more requests. This way we can create an account and store any local information we might need for the user but not have to deal with putting the customers information at risk. The process is a little more in depth by authenticating every step of the login process, making sure it’s not intercepted, and having a different client requesting the information. This can be achieved by using a state value, that only the requesting user will have. We will then compare this value to insure it is still the same client, and deny any non authorized requests. This also makes it very easy to create accounts and to login the user. We now avoid the customer from having their credentials stored in two different locations, this reduces their chances of being involved in a breach. This would be the easier generally more secure method for someone who is not very experienced and even for someone very experienced. The great thing about tokens as well is, they are always retractable by google, if the user wants to revoke all access to a token ( site), they can. Once invalidated, no further request would be able to access any information from the user. 

Categories
Uncategorized

Week 6 Blog

This week has been a little bit of a struggle in trying to finish my projects for all my classes, falling a little behind. Have the mental focus to push through all the assignments has been very tough, usually when I’m in Corvallis things are a lot easier because the environment is based around school and work. However at home, it’s different, you got family and friends that are always around being distractive. CS444 specifically has been the biggest challenge, online lectures are average about an hour asynchronous. Which makes it more difficult, the learning experience is not very good. I understand with programming everything will be mostly done entirely online, however, when learning I think having the classroom environment and people in the same position makes it easier. If you get stuck or need different points of view on a subject, they are there and together learning becomes easier and more fun. My entire university experience has been roughly semi-difficult, mostly all being hard due to time management, now that it’s at home it becomes that much more difficult. 

On the bright side, I have finally decided to start running the layout for my developer website. This website will consist of very userfriendly laid out tutorials for things that aren’t very common or very complicated to understand. I find that many tutorials online arent very detailed or explained in ways that aren’t very easy for most people to understand. So I hope that I can create content for just a couple of things to start off with, just to keep others posted. I will deliver my content mostly through social media initially like Instagram to explain or talk about small things. With the website containing more information and very detailed and easy tutorials. This will also serve as a way to demonstrate what I can do and use it on my portfolio. However I will see if others have ideas that I can incorporate or things they would find very helpful or useful.

Categories
Uncategorized

Week 5 Blog

One challenge I faced this week was encrypting passwords and how to properly manage them. It’s interesting to see how many ways this can be accomplished and things we should never do. I have made a couple of applications that require some sort of password storage initially, when I was back in high school, I only used a base64 encoding. Which is laughable, but I was learning and in my mind, that was somehow working because you couldn’t see their password. That’s all that mattered at the time, however all it took was a simple decode(pass) to get back to the original password. Then I started using some sort of hashing that is nonreversible. This was definitely a better option but I never really looked at data breaches and at real-life events that resulted in breaches. So this week I looked more into it, I did a little more research for my current team project. I found lots of interesting information. 

One thing with hashing is that a lot of common passwords are simply already out their with their current hash. So simply storing a hashed password for say “password123” in hash like maybe “somerandomhash”, is not good enough anymore. Since running something like sha256(password123) will always result in the same hash, it makes it easier to guess. You then simply compare that hash against the common password’s hash and you find out the password. So I discovered that there are newer techniques to protect against this called salt. The salt method uses a unique text to append to the password when creating the hash. That way you cannot simply search for already decoded passwords.

So this makes it very hard for even with a data breach and direct access to the unique text and hashed password to be decoded. To add even more security you can repeat this process and do something like sha256(salt + sha256( salt + password)). This isn’t necessary however. Another method called pepper is also a very good choice, for example sha256( pepper + sha256(salt + password)). Where pepper is the same random text for all users and salt being unique. The pepper is never stored in the database which makes it even more secure but can be a pain in case of a breach to deal with. This is a good approach but there is other things apparently that you can implement in the communication/transmission of the password from client to server that can also be made more secure.