Author: Michael

In my last security post I discussed the fact that good secure passwords and proper storage and use are every web user’s responsibility. This is even more important for those of us working as web developers.

Providing a username and password to a website or application does primarily only one thing, and that is to prove that you are who you say you are. You really need to be trusted by the service you are using. However, the flip side to that is that you want there to be NO OTHER PEOPLE that can impersonate you. You, and you alone have the legitimate right to your information. It is a matter of proving identity.

Once you login, then the service you are talking to needs to prove to you that they are who they claim to be. This pairing of proven identities sets up a trust relationship. You and your web browser need a two way trust with the service on the other end of the network connection. However, from its inception the internet was a trusting place so the connections did not need built-in security. Originally, it was university researchers sharing information with other researchers. There was an inherent trust in that community. But, then many people and companies started using the internet for many different reasons, most legitimate, but unfortunately many are malicious. Secure Socket Layer (SSL) is a technology for creating a secure tunnel from the inside of your computer to the inside of a trusted service you are connected to.

How SSL works is very complicated and fortunately you don’t need to understand it all. Here is an excellent and relatively short explanation of how SSL certificates work: https://www.cloudflare.com/learning/ssl/how-does-ssl-work/ Please take a few minutes to at least browse through it to understand the basics.

Now that you have that basic understanding, we need to consider the two basic concepts that have to be carefully considered to be safe(r) on the internet:

Identity of you and your browser, and the web server and its owner. And a secure communication channel between the two programs. Certificates do both of those things.

When you enter a URL or click on a link, the URL starts with a protocol string which is either HTTP:// or HTTPS://. The S stands for Secure. You can freely communicate over HTTP protocol, but it is NOT secure. If you want it secure then it needs to be HTTPS.

Insecure connection

As an example of an insecure website, try this (no really, it’s OK): http://digitalparadox.org/ Notice the ‘http://’ and when you get there the address bar of your browser should say ‘Insecure‘. If you forget the ‘S’ on a site that is secure, it has the ability (not guarantee) to forward your request to httpS:// to ensure it is secure. Try it and notice if it makes the switch.

Secure connection

When your browser connects to a web server, AND you are using HTTPS protocol, then your browser and the web server exchange certificate files that are used to establish the secure channel. Both programs can determine for certain whether the other computer sent a properly secure certificate. When that is done, your web browser should clearly indicate the connection is secure. This is often done by displaying a lock icon to the left of the address as in these examples. Notice that these examples are all this training site: MichaelKentBurns.com which has a proven certificate.

Unfortunately Chrome browsers sometimes use an icon that is not clear to my mind. It is meant to indicate a two way secure connection. Here it is:

Secure connection to Uncertain site.

So far we have been primarily interested in the secure connection, but we have not addressed the identity of the website. Built into a properly formed certificate is the identity of the service and the identity of several independent but trusted certificate authorities that know about this claim of identity. Basically, your browser can decode that certificate and contact those independent authorities to check out the claims. If all that checks out, you can be quite certain that all is well.

However, a less secure type of certificate can’t be proven by your browser. In this case then your browser will make it plain to you. One example that I am certain of is our demo site: https://demo.MichaelKentBurns.com . We have a certificate but it’s not proven yet. The first time your browser encounters such a site it will make it very plain by showing you a severe warning instead of the website you were hoping for.

Not wanting to assume that you understand the subtleties it simply says ‘Your connection is not private‘. The connection is secure, but you can’t be sure of the destination. HOWEVER, don’t be too quick to barge on past the warning! This is where:

I give HIGH COMMENDATION to Samuel.

When he encountered this he said:

“… the problem that i have found it concern the security of this page, my software of protection had to notify me that, …”

Samuel, an astute student!

Always stop at this warning and evaluate. Double check your instructions. Make sure the site you are going to is a low risk. Your important accounts and high risk sites should NEVER cause this warning. In this case, it was our demo site that was still under construction. This warning is what prompted us to enter Issue #24. It is that issue that I have been working on that brought all of this to my attention. This is an important issue that should never be trivialized.

But, once you read the warning, you are provided with an ‘Advanced’ button. If you click that, you get a little more information:

Notice, at the very bottom line in fine print, there is a link that lets you proceed to the site. If you click that, you get your site but there is a still a stern warning in the address line of your browser:

Checking the details of a site certificate.

In some browsers there is a link or a button that will show you the details of the certificate.

That’s not usually very easy to do with some browsers. There is an easier way:

https://www.sslchecker.com/sslchecker

You can enter the domain address of any site and it will give you the details. For example:

Now, you try it yourself: https://www.sslchecker.com

Put in a site that you really depend on like Upwork.com. A really impressive one to try is google.com, give it a look.

Your responsibility as a web browser and developer.

So, what is the bottom line?

• Look for the lock!
• Beware the warning!
• If in doubt, check it out with https://www.sslchecker.com or the features built into your browser.
• Make sure the sites you are responsible for have a good certificate.

Now, dear students, it’s time to take action. Leave a comment below.

What did you know about this before reading this page?
What did you learn?
Better yet, what are you going to change?
Whose responsibility is it to check certificates?

NOTE: This is one of a few occasions where I will post that my readers should, and my students MUST stop and read. So, I’m going to use a label we use on our most important GitHub issues:

I know that network security is such a bother! But, please, read this carefully! Network security begins with the user, and that means you! It also is a primary responsibility of web and other software developers, so that means you! But you may be thinking that you are just a front-end developer, not a full stack expert. Wrong! Yes, the full stack guru needs to be extra trained and vigilant, but like any chain, it is only as strong as the weakest link. Don’t let that be you. The end user is a link to. So, that is where we are going to start.

This is just the first installment of a major section that we will add to this training site. So, settle in and pay attention. There will be a call to action at the end of this and every security post.

Security Lesson #1 – passwords

Why passwords are important:

We all have so many online accounts and almost all of them require usernames and passwords. In the password vault I share with my wife Mary, we have 692 passwords!! But, we have all been advised that it is important to have good passwords to keep our digital lives secure.

Think of the types of accounts that you might have:

• Social media accounts (Facebook, Twitter er X, Instagram)
• Email account (**@gm***.com)
• Online shopping (Amazon.com)
• Online banking (checking account, PayPal, credit card)
• Freelancing profile (Upwork.com)
• Software repositories (GitHub.com)
• Smart phone
• Personal computer
• Work account

Just think if those were not password protected. You might think that some of those accounts are not that important because you don’t have anything terribly valuable. But consider that thieves and hackers don’t know that you don’t have anything valuable. They just hack and if they get in they look for valuables. But, many hackers are not looking for valuables, they are looking to cause trouble.

Is your social media presence valuable to you? What if your account were hacked and a malicious person decides to post nasty things while posing as you? What would that do to your relationships and social trust? What if your work account was hacked and your companies private information was stolen or damaged? Even if you don’t control any valuable information (not likely), if a hacker gets in your login account they can use that to launch a cyber attack on many sites. Many hosting services will quickly detect such an attack and their response is to simply shut down the machine. Now, you and your co-workers can’t login to work the next day, and maybe the day after. Not good.

Consider that list and you decide what the value is on just five of those accounts.

What makes a good or bad password?

Now, open a separate browser window or tab on this: https://www.passwordmonster.com

In that page, you can type in the passwords that protect your privacy. Pay attention to the “Time to crack your password:”

Now, go read this article: https://www.techopedia.com/password-manager/the-most-common-passwords-weakest-passwords

Where to store your passwords?

Assuming that you have now created some great passwords, you may realize that you are NOT going to be able to remember them. Please don’t write it on a sticky note on your keyboard!! (I’ve seen it done!). The previous article mentioned several good password vault programs. I personally use 1Password. It’s been around for years and is cross platform. My wife and I share an account and it synchronizes to all of our devices and operating systems. It uses biometrics where supported.

Good password managers also contain a feature that checks the security of your passwords. 1Password calls that feature ‘Watchtower’. With one click it checks all of my passwords. It evaluates:

• The strength of each password
• checks for passwords used for multiple sites (very bad idea)
• websites which are known to have been compromised (your password is at risk)
• unsecured websites (http:// rather than https://) More about this soon…
• sites that offer two-factor authentication that you are not using but should
• sites that support Passkeys (much more secure than even two-factor)

However, you often need your passwords handy in your web browser and your ssh terminal program. 1Password (and others) have plugins to most browsers so it is at the ready to plugin your password when a sites prompts you to login. I also recommend an ssh (and sftp) program called Termius that has a password vault built in. Once I have unlocked Termius and connect to a site, it automatically retrieves the username and password from its vault.

Call to action:

You should have followed each link and chosen your five most important passwords.

• How strong were they?
• How long would it take to crack them?
• Did you decide to change them?
• Where did you store the new better password?
• Have you considered a password manager?
• How secure are your accounts now?

If you are one of my students, you MUST leave a comment on this post and answer each of those questions. I would be interested any any other comments as well.

In my previous post (#6) I described how there were speed bumps in the team’s process that resulted from them working as individual developers often do. However, this created a few issues now that they were working on a team project. I was able to use that as a teaching opportunity to not only explain why they hit the bumps, but how to use the GitHub project Issues list to rapidly detect the speed bumps, address the issue as a team and smooth the road while improving their process. That lesson was on a Monday during their weekly scrum (team meeting). They understood the usage of labels and new issues and agreed that it would help.

As they worked that week, on their Friday, while I was happily sleeping 7 hours away, Efatha hit a speed bump and immediately raised a red flag and described his problem in the appropriate issue. Doing that alerted the other two guys. When alerted, they went to the issue and sized up the situation. Philemon identified the problem, and posted a link to a specific piece of code he had pushed. He followed with a detailed step by step that would allow Efatha to access the right code. Ash quickly replied that he had just tested the instructions and verified that it was indeed working for him. Efatha made an additional comment and went on with working. Problem solved!

All the while, I was still asleep. When I woke up and looked at my email I saw a flurry of 6 emails to read. When I looked at them I saw that they were a nice thread of 6 comments from a single issue in GitHub. I quickly read through them and realized that they had identified a problem, fixed it, tested it, and were done. All while I was sleeping. All I had to do was sit and be amazed at how they had implemented the process improvements and were now working very effectively as a professional team.

WAY TO GO TEAM!!

Last week as the cohort-1 team was busy working on their respective parts of the demo project they hit a few speed bumps. There is certainly no surprise there. The work is complicated and with everybody busy working on their assigned issues in the same project repository it is inevitable that we would discover issues that we did not anticipate. We can choose to view these as setbacks, but they really are a reality and more importantly an opportunity for learning and process improvements.

Take for instance the fact that both Efatha and Philemon were creating different versions of basically the same application. It is not unusual for a web page to be called index.html. The other complicating factor is that they both decided that since their pages were just test versions of what we hope to be the real application for this project, they would put their files in the /test directory. Efatha pushed his first and when Philemon got around to pushing his copy from his repository there were now two ‘test/index.html’ files that pushed. When Philemon merged his into the shared GitHub repository there was a conflict. The end result is that his code overwrote Efatha’s.

Efatha was a bit surprised by this and he was confused as to how he should proceed. He set about trying to figure out what to do about it. He commented to me in a message in the Upwork discussion, and I said I would look into it. However, the Upwork discussions are unique to each developer and myself. When he asked me what to do, Philemon was not notified of the issue. Until I figured it out, I was having two private conversations and I became the middle man.

One of the important principles of team dynamics is that at some level each team member should have a high level view of what the other team members are doing and any problems they might encounter. Since we were communicating these issues through private Upwork messages there was not a common view of the situation. The first lesson is that these kinds of issues that block progress must be communicated in the Issues list of the project repository. Each of them were working on their own top level story. Efatha’s story was Issue #5, and Philemon’s was Issue #6. They were each focused on their issue and not seeing what was happening to the other.

The proper way to communicate these kinds of issues is for everybody to have a common view of the project, the issues each person is working on, and most important any high priority issues. The solution is a proper set of Issue labels. I added new labels to the issues list:

• A bright purple label named “Stuck !!” is to be applied to an active issue that gets stuck. In Efatha’s case the “Issue #5 creating the form with html and css” now needs a “Stuck!” label. That way when each team member reviews the Issues list they see that Efatha is stuck in his primary issue. In addition to applying the label, Efatha should have simply added a comment to the issue explaining his problem. That way when I and/or Philemon reviews the issues list (which should be done daily) we would quickly see that Efatha’s primary task was “Stuck!”. Then we would simply open that discussion and see the problem. So, early this morning I did what Efatha did not yet know he could have done. In our meeting we discussed it and figured out the solution. Part of the solution is that we now need a new issue.
• That new issue is “#10 We need to decide the top level structure of our demo project.” I entered that and explained the problem and my proposal for how to setup the directory structure and how to name files. I also created a new label colored red: “High Priority!!”. If you hover over that label it explains: “Drop what you are doing and pay attention!”. The purpose of this label is a visual cue that each team member when daily reviewing the Issue board would see this and do as suggested. They should suspend their normal work, open the new issue and read about the situation. They would then read my suggestion and enter a comment that would either agree with my proposal or propose an alternative solution. Sometimes they may decide it’s not up to them, and they should enter a comment to that effect and then move on with their normal work. This issue was not really new because Ash had commented that when reviewing Efatha’s push for his issue #5. But, since it was just a comment in a list of comments nobody paid close enough attention to realize the importance. When I took Ash’s comment and made a new issue of it, I also added “High Priority!!”. Now, each team member should notice that, read the conversation, and add their comment. Quickly we should arrive at a consensus opinion that someone should take responsibility to implement a solution. When that solution is in place and pushed, they will update it with a comment that should cause the rest of the team to review their fix and comment that they agree that the solution fixes the problem. At that point someone will remove the “High Priority!!” label.

One more example of these labels is in Philemon’s Issue #6: “creation of the json file structure and javascript code” which is his “Active” “Main story”. During his demo of the current state of that, he mentioned the problem that browsers don’t allow Javascript code to write files to the user’s local filesystem. This is an important security mandate and rightly so. However, our desire to write to the /responses folder is only a temporary solution which will go away when Ash gets a backend server running that allows our code to send the Json data directly to the backend for permanent storage. So, I proposed a temporary workaround that allows us to demo his code, see the submitted json file, and get it stored. As a result, I added the “Stuck!” label and explained the problem and my proposed solution. I finished my comment with this: “Give it a try. If that works for you, add a comment here and then remove the Stuck!! label and move on .” When Philemon sees my suggestion and tries it, and agrees that it works, he will comment to that effect, remove the “Stuck!!” label and then move on with his work.

The bottom line on this post is:

• We have new labels that get attention and cause the team to act.
• Each team member should daily take a look at the issues list and look for the labels “bug”, “Stuck!”, and “High Priority!!” and then stop and consider their role in the solution.
• Each team member is empowered, encouraged, an able to enter new issues and add or remove labels to them as appropriate.

So, please digest this post, make an effort to add these tools to your toolbox, and then comment on this post so I know you have absorbed and commit to applying these tools. Thank you for your cooperation.

It’s now your turn to act.

I first met Destin in Bukavu in May 2023 during my first visit. He impressed me then with his breadth of knowledge in web development. His review of this site has solidified that impression. He has a wealth of information and does his research very thoroughly. As a result I invited him to edit the Full stack page and give it much needed material. He has done that well and has come up with much more material that needs to be added in several other pages. So, stay tuned for those enhancements.

You can find him on the contributors page and get more information him and his efforts on his specific contributor page.

Philemon Bahati has been a friend for over a year now and I had the pleasure of meeting him in person in April/May 2023 in Bukavu, DR Congo where he lives.

He has been actively reviewing this site and taking on challenges. During his reviews he has made a number of recommendations and authored some significant contributions. In recognition of that, I am now officially adding him to my contributors page. Please welcome him and be sure to visit his contributions page. I’m sure there will be new material there soon.

His first contribution is available on his contributions page and is referenced from the front end web page.