Nearing the end of this quarter, this will probably be my last journal entry about this research project for a while. There are some things that I am very interested in that came up during my research on password authentication methods and the attacks and defenses applied to it, so I may provide some more information here as that unfolds.
When being introduced to this class project I thought I would enjoy it as much as my other writing assignments I've encountered at school; that is hardly at all. I was very mistaken, topic selection and being free to cover any/all aspects that I wanted made it much more enjoyable, and I would not be opposed to doing this project again if I had to. I learned a lot and I felt a very satisfied with my final outcomes, and I like to think that the material I presented to the class helped to inform them and possibly get them interested in the security matters present in IT.
I need to thank my teachers and classmates for being supportive and providing good feedback and prompting throughout.
I have chosen to provide a link to a view-able copy of my research paper, Password Authentication, both here and on our cohort website. We built this website last quarter and it is still functioning, although with a few hiccups here and there as some services seem to be being turned on/off at the server end. This is mostly due to our unfamiliarity with how AWS works and we expect to get these problems sorted out. I did forget my password and hence had to use the password reset function, which worked properly and my access is restored.
Edit:
Here is an info-graphic I made that explains the core ideas that my research discussed, essentially that password attacks get stronger as more passwords become available. Link to the original. Feel free to share this with anyone and/or take my research done above and improve upon it, as long as the proper citations are included.
Information Systems and Security
Sunday, June 11, 2017
Friday, June 9, 2017
Week 10 - Progress Report
This past week was mostly about getting the first draft of the research paper together, and then reading and responding to two other papers. I feel satisfied with the work I put into my paper and have so far gotten some very useful feedback that I will use before the final submission. When it was being written I found out that I could have gone into much more detail than I did but didn't due to length reasons. Each specific topic in the paper (hashing, attack types, etc) could easily be a research topic in its own write, so my overall goal was to present an overview that covered all the key aspects deep enough that readers would be able to make informed decisions.
The length of the paper worried me at first (8 - 15 pages) because I knew I would rather do it in single spaced format to make it look and feel more professional, but I was soon pushing the 15pg mark without any issue. I could have easily written another 10 or so pages about the specifics of password lists and analysis, examples of attack implementations, discussed more about how databases get divulged, covered the cost/efficiency factor more in depth. I did not cover non traditional attacks or the effects of quantum computing either, choosing to leave these out because they don't easily fit in the structure nor do they really effect the outcome/conclusion.
The most surprising thing I learned about research during this project is how much the topic itself plays a role in the research process. Security has always interested me and the attack/defense nature that I explored was fascinating, leading me to do more and more research. Contrast this with other scenarios where the research topic might get chosen for you and I could see how much harder that could be, especially if the topic is uninteresting or boring.
Overall I'm satisfied with my research and feel much more qualified to discuss passwords and authentication in the future. Being aware of a topic is often half the battle in the first place, and my hope was that people would be made more aware of how password systems work/break so they could make informed decisions as IT professionals.
The length of the paper worried me at first (8 - 15 pages) because I knew I would rather do it in single spaced format to make it look and feel more professional, but I was soon pushing the 15pg mark without any issue. I could have easily written another 10 or so pages about the specifics of password lists and analysis, examples of attack implementations, discussed more about how databases get divulged, covered the cost/efficiency factor more in depth. I did not cover non traditional attacks or the effects of quantum computing either, choosing to leave these out because they don't easily fit in the structure nor do they really effect the outcome/conclusion.
The most surprising thing I learned about research during this project is how much the topic itself plays a role in the research process. Security has always interested me and the attack/defense nature that I explored was fascinating, leading me to do more and more research. Contrast this with other scenarios where the research topic might get chosen for you and I could see how much harder that could be, especially if the topic is uninteresting or boring.
Overall I'm satisfied with my research and feel much more qualified to discuss passwords and authentication in the future. Being aware of a topic is often half the battle in the first place, and my hope was that people would be made more aware of how password systems work/break so they could make informed decisions as IT professionals.
Sunday, June 4, 2017
Week 9 - Journal
Research and Decision Making
The impact of research on the decision making process will greatly depend on the extent of the research being conducted, with higher levels of research yielding more accurate but more costly to produce results. Depending on the time-frame for the required decision, fitting in at least some level of research will likely lead to a better outcome. Deciding without research will be quicker and can be required at times where time is short, this is where having experienced people around you will be immensely helpful.
As an example, I can consider how research would have impacted a recent project that I was involved in that involved building a website. In this project we built the website from scratch and uploaded it to a server. The selection of the server was decided based upon input from both faculty and students, and our eventual decision to use Amazon Web Services meant our website could be quickly uploaded and ran but did give us a major hiccup down the road. Getting HTTPS encrypted communication was proving to be a real pain, and negatively effected our efforts to get the final version running, especially because we were implementing a password authentication system that relied on encrypted traffic.
More research done at the start of the project might have steered away from AWS if we knew of the complications it would introduce. This realization would be dependent on how thorough we were with the research, obviously if we didn't specifically check to see how easily verified HTTPS could be enabled it would probably not effect the outcome. What would have probably been needed is to have each team member (there were 6 of us) research a specific category, someone researching security might have come across how AWS handles HTTPS and alerted the team of the findings. A week spent on this would probably not have negatively effected out outcome at all, and could possibly have made us aware of some upcoming challenges (if we still decided to go with AWS).
In the end it is really a time tradeoff, can you afford to sacrifice some time to gather accurate information before making a decision? I would say the trade-off is almost always worth it, but I can understand that there are times where the time simply isn't there.
The impact of research on the decision making process will greatly depend on the extent of the research being conducted, with higher levels of research yielding more accurate but more costly to produce results. Depending on the time-frame for the required decision, fitting in at least some level of research will likely lead to a better outcome. Deciding without research will be quicker and can be required at times where time is short, this is where having experienced people around you will be immensely helpful.
As an example, I can consider how research would have impacted a recent project that I was involved in that involved building a website. In this project we built the website from scratch and uploaded it to a server. The selection of the server was decided based upon input from both faculty and students, and our eventual decision to use Amazon Web Services meant our website could be quickly uploaded and ran but did give us a major hiccup down the road. Getting HTTPS encrypted communication was proving to be a real pain, and negatively effected our efforts to get the final version running, especially because we were implementing a password authentication system that relied on encrypted traffic.
More research done at the start of the project might have steered away from AWS if we knew of the complications it would introduce. This realization would be dependent on how thorough we were with the research, obviously if we didn't specifically check to see how easily verified HTTPS could be enabled it would probably not effect the outcome. What would have probably been needed is to have each team member (there were 6 of us) research a specific category, someone researching security might have come across how AWS handles HTTPS and alerted the team of the findings. A week spent on this would probably not have negatively effected out outcome at all, and could possibly have made us aware of some upcoming challenges (if we still decided to go with AWS).
In the end it is really a time tradeoff, can you afford to sacrifice some time to gather accurate information before making a decision? I would say the trade-off is almost always worth it, but I can understand that there are times where the time simply isn't there.
Friday, June 2, 2017
Week 9 - Progress Report
Presentation is accomplished! With that stress now out of the way I can focus much more on the task of building the research paper. The first draft is due in a few days, and I have already made an outline of all the areas I need to cover and am in the process if filling in detailed information.
Reflecting on the presentation, it actually didn't feel too bad once I got in the swing of things and I did feel prepared to present and have a discussion with the audience. There were a few topics that I forgot to mention that I had planned on (just lost in the moment), but it still seemed to go on for a significant duration. I enjoyed the questions that the audience had the most, I loved answering their questions and hearing their thoughts. Their feedback makes me confident that my paper will be covering all the necessary features, although I intend to delve into some of the areas that I sort of skimmed over in the presentation (specifically the trade-offs of hashing costs, password complexity and memorabilia, and limited login attempts).
I will also include a mention of why hash salts are traditionally stored with the hash, a popular question that I think needs a strong answer to. In the presentation I said that the purpose of the salt was to make rainbow-table attacks impossible, and this is true, but the second feature that I forgot to mention is that they also make identical passwords hash to different hashes.
I think my biggest issue this week is just finding time to work on my research paper. I waited on writing most of the paper until my presentation was done so I could take the feedback and help polish the writing, something I think will improve the final result. I will finish the paper on time for the peer review process, it will just take a few late nights here and there. My sources and ideas are sorted out and available, I just need to write.
Reflecting on the presentation, it actually didn't feel too bad once I got in the swing of things and I did feel prepared to present and have a discussion with the audience. There were a few topics that I forgot to mention that I had planned on (just lost in the moment), but it still seemed to go on for a significant duration. I enjoyed the questions that the audience had the most, I loved answering their questions and hearing their thoughts. Their feedback makes me confident that my paper will be covering all the necessary features, although I intend to delve into some of the areas that I sort of skimmed over in the presentation (specifically the trade-offs of hashing costs, password complexity and memorabilia, and limited login attempts).
I will also include a mention of why hash salts are traditionally stored with the hash, a popular question that I think needs a strong answer to. In the presentation I said that the purpose of the salt was to make rainbow-table attacks impossible, and this is true, but the second feature that I forgot to mention is that they also make identical passwords hash to different hashes.
I think my biggest issue this week is just finding time to work on my research paper. I waited on writing most of the paper until my presentation was done so I could take the feedback and help polish the writing, something I think will improve the final result. I will finish the paper on time for the peer review process, it will just take a few late nights here and there. My sources and ideas are sorted out and available, I just need to write.
Sunday, May 28, 2017
Week 8 - Journal
When I first started theorizing what my research question might be, I just knew it would be something security related. I ended up choosing password authentication because it encapsulates a few interesting aspects like hashing and varied attack methods. It's these sorts of things that really interested me, especially the attack/defense aspect. During my research there was one idea that I found extremely interesting; how non-standard technological advancements pose threats to classically based encryption and hash algorithms.
This is likely to manifest itself in two main categories, either quantum computers or machines developed on highly specialized microprocessors that are extremely efficient at problems. Take quantum computing, a newcomer to the scene; the issue revolves around the fact that they are theorized to be efficient for factoring numbers. This break one of the basic building blocks of RSA public key encryption; that multiplying numbers is easy and factoring much harder. If a device comes along that can easily factor the huge numbers that are used to provide encryption. There is also a similar problem with elliptic curve cryptography, these methods developed with classical computing in mind are at severe risk to non-standard attacks.
While not something I decided to do much research on, this is something that should be at least talked about because it has potential consequences for vast areas of IT. The possibility that an entity could get enough quantum computing power to trivially break vast amounts of encryption is very real, in fact probably a certainty. These kinds of game-changing moments are what make IT so interesting to myself and many others, and it's up to us to assess the challenges and develop responses.
This is likely to manifest itself in two main categories, either quantum computers or machines developed on highly specialized microprocessors that are extremely efficient at problems. Take quantum computing, a newcomer to the scene; the issue revolves around the fact that they are theorized to be efficient for factoring numbers. This break one of the basic building blocks of RSA public key encryption; that multiplying numbers is easy and factoring much harder. If a device comes along that can easily factor the huge numbers that are used to provide encryption. There is also a similar problem with elliptic curve cryptography, these methods developed with classical computing in mind are at severe risk to non-standard attacks.
While not something I decided to do much research on, this is something that should be at least talked about because it has potential consequences for vast areas of IT. The possibility that an entity could get enough quantum computing power to trivially break vast amounts of encryption is very real, in fact probably a certainty. These kinds of game-changing moments are what make IT so interesting to myself and many others, and it's up to us to assess the challenges and develop responses.
Friday, May 26, 2017
Week 8 - Progress Report
With my presentation coming up shortly, my focus this week has been almost entirely on that. I plan to finish my first draft of the paper over the weekend and then draw from it the key elements that I will be presenting.
Next week I will be finalizing the draft to be submitted for peer review, so I intend to take the presentation process to help to internalize the concepts and feedback to provide that extra bit of input for the paper. Giving the presentation before submitting the draft provides a good opportunity to help polish the final paper, so I would be silly to not take advantage of it.
Shorter than usual blog post, so here's an interesting video about the recent ransomware attack.
Next week I will be finalizing the draft to be submitted for peer review, so I intend to take the presentation process to help to internalize the concepts and feedback to provide that extra bit of input for the paper. Giving the presentation before submitting the draft provides a good opportunity to help polish the final paper, so I would be silly to not take advantage of it.
Shorter than usual blog post, so here's an interesting video about the recent ransomware attack.
Wednesday, May 24, 2017
Presentations - Not the Worst Thing Ever
When it comes to making and giving presentations, there are a few basics that I've learned over the years that can make the process much easier on yourself and your audience. Presenting has never come easy for me (as an INTJ) but it really is a necessity for many positions out there, knowing how to articulate your ideas to groups of people so that they are fairly presented and favorably received could make a world of difference, in the right situations.
My first tip is to know your audience, try to tailor your presentation to match their skill levels. You don't want to lose your audience in the details, nor do you want to leave them with no background information at all. Ideally the presentation should briefly cover some basic aspects that everyone in the audience should know, and then the rest of the time should be spent on new/interesting material.
Next tip; don't read your slides word for word. In my experience reading from slides can reflect poorly on the presentation, especially if they are text heavy and that is the only things you say. Slides should offer short and interesting key ideas as jumping off points for you to talk about. This does require more preparation but I think it shows that you are more dedicated and interested in the subject, it shows that the ideas are coming from you and not the slides. You want the audience to be listening to what you have to say, not trying to read your slides to glean information from them.
Lastly, try to look around the room and remain engaged with the audience. A general good tip for public speaking, the idea is that you want to be talking to the audience, not just into the ether somewhere. A big part of this is being confident in what you are presenting and speaking like you know what you are talking about, once you can do that talking to groups of people does become much easier.
Public speaking is not my forte, but by doing the three things mentioned above I have found that it is not unbearable. (Especially true in the IT field, where many of us are in the same boat)
My first tip is to know your audience, try to tailor your presentation to match their skill levels. You don't want to lose your audience in the details, nor do you want to leave them with no background information at all. Ideally the presentation should briefly cover some basic aspects that everyone in the audience should know, and then the rest of the time should be spent on new/interesting material.
Next tip; don't read your slides word for word. In my experience reading from slides can reflect poorly on the presentation, especially if they are text heavy and that is the only things you say. Slides should offer short and interesting key ideas as jumping off points for you to talk about. This does require more preparation but I think it shows that you are more dedicated and interested in the subject, it shows that the ideas are coming from you and not the slides. You want the audience to be listening to what you have to say, not trying to read your slides to glean information from them.
Lastly, try to look around the room and remain engaged with the audience. A general good tip for public speaking, the idea is that you want to be talking to the audience, not just into the ether somewhere. A big part of this is being confident in what you are presenting and speaking like you know what you are talking about, once you can do that talking to groups of people does become much easier.
Public speaking is not my forte, but by doing the three things mentioned above I have found that it is not unbearable. (Especially true in the IT field, where many of us are in the same boat)
Subscribe to:
Comments (Atom)
-
As I near the midpoint of this research project it will become increasingly important to keep track of my efforts and organize them to ensur...
-
One interesting ethical issue that I hadn't really thought of before is the legality of breaking and/or analyzing illegally obtained pas...
-
Yes, I know, libraries may seem outdated with all the technological advances we have made that allow information gathering, such as services...
