Internet of Things (IoT) Security Issues

In the past, I discussed how the Internet of Things (IoT) could eventually cause a wealth of problems on the Internet, including security breaches, in a number of my books and articles. Some of my strongest warnings came in Build Your Own PC on a Budget and Security for Web Developers, but I included warnings in other places as well. Unfortunately, the worst case scenario has occurred according to the ComputerWorld article, Armies of hacked IoT devices launch unprecedented DDoS attacks. Yes, your DVR or smart television might have turned into a zombie at this point and now works for someone else committing crimes. All it takes is a little negligence on your part and your device will take a walk on the dark side.

The article is worthwhile reading because the statistics sound like something out of a bad science fiction novel. If anything, my warnings were too tame and I should have used my imagination a bit more in exploring just how bad things could get. Yet, I’ve received e-mail from readers who found the warnings I did provide barely believable. It didn’t seem possible that something as simple as the router installed to provide broadband support for your digital telephone could possibly cause any sort of problem. After all, your old telephone system never went on the attack. The thing is, any device that connects to the Internet today probably has enough intelligence to do harm, especially the IoT devices that everyone assumes just work.

IoT devices are actually some of the best targets for hackers. The users who have them barely know how they work, have no clue that they should change the password, and wouldn’t care even if they could figure it out. After all, the goal is to see Sunday afternoon football, not to configure security for a device. Vendors share in the blame because anyone with even a modicum of common sense would know that users have no desire whatsoever to change device passwords. IoT devices should go out with a unique password printed in a place that the user can easily find on the device, should it ever become necessary to access the device (and it might not ever become necessary). If hackers faced a unique default password for every device, the IoT devices would likely remain relatively secure unless hackers could somehow figure a pattern out in the password assignments. Ensuring the unique password is printed on the device means the user won’t lose it.

It’s not as if changing IoT device passwords is easy anyway, so hackers have every reason to believe that the default password is still in place for the majority of these devices. A recent device purchase pointed out to me that some IoT devices view even password changes as unwelcome user fiddling—it took nearly 20 minutes of reading to discover how to change the password using an arcane set of remote control clicks. Until this situation changes, you must expect that hackers will continue to use IoT devices to perform various kinds of attacks and that device owners will continue to remain oblivious about their cherished device’s life of crime. Let me know your thoughts on IoT security at John@JohnMuellerBooks.com.

 

Mac Gatekeeper Error

A number of my books, such as C++ All-In-One for Dummies, 3rd EditionBeginning Programming with Python For Dummies, Python for Data Science for Dummies, and Machine Learning for Dummies ask readers to download an IDE or other code and install it on their Mac systems. The problem is that the Mac system won’t always cooperate. For example, you might see an error dialog like the one shown for Code::Blocks:

The Gatekeeper error tells you that it won't allow you to install software from unknown publishers.
Your Mac won’t let you install software.

The problem is one of permissions. The default permissions set for newer Mac systems restrict you to getting your apps from the Mac App Store or from vendors who have signed their files. Fortunately, you can overcome this problem either temporarily or permanently, depending on how you want to use your Mac. The Fix the “App can’t be opened because it is from an unidentified developer” Error in Mac OS X blog post provides you with illustrated, step-by-step directions to perform the task using either method. Let me know if you encounter any other problems getting your Mac to install the software required to use my books at John@JohnMuellerBooks.com.

 

Working with Code in e-Books

Most of my technical readers now use e-books instead of paper books. Of course, there is a convenience factor to storing your entire library on a Kindle, even if it’s a software version of the Kindle. Of course, there are all sorts of e-book formats for your desktop system as well. The point is that electronic format makes a lot of sense when dealing with technical books.

However, e-books can cause some interesting problems and I’ve encountered a few with a number of readers now. The most important consideration is that you can’t cut and paste code from an e-book directly into your IDE and expect it to work. There are all sorts of reasons for this exclusion. For example, cutting and pasting may insert special characters into the output stream or the resulting paste may not have white space in the right places. A common problem is that publishers often convert regular single and double quotes into curly quote equivalents. The two kinds of quotes (both single and double) are completely different and the second type definitely won’t compile.

The best option when working with an e-book is to view the code in the e-book, but still get the downloadable source code for the book from the publishers website. I always provide a blog post detailing where to obtain the downloadable source for a book, when you need source code to use the book. If you can’t find the downloadable source, always feel free to contact me at John@JohnMuellerBooks.com. I want to be sure you have a great reading experience, which means having source code that actually runs in your development environment.

Another potential problem with e-books is that you may see unfortunate code breaks (despite the efforts of the publisher and myself). When you need to understand how white space works with a programming language, always review the downloadable source. The fact that the downloadable source compiles and runs tells you that all the of white space is in the right place and of the correct type. Typing the source code directly out of your e-book could result in added carriage returns or other white space errors that will cause the code to fail, even though the commands, variables, and other parts of the code are all correct.

As always, I’m open to your questions about my books. If you don’t understand how things work, please contact me—that’s why I’m here.

 

Is Security Research Always Useful?

Anyone involved in the computer industry likely spends some amount of time reading about the latest security issues in books such as Security for Web Developers. Administrators and developers probably spend more time than many people, but no one can possibly read all the security research available today. There are so many researchers looking for so many bugs in so many places and in so many different ways that even if someone had the time and inclination to read every security article produced, it would be impossible. You’d need to be the speediest reader on the planet (and then some) to even think about scratching the surface. So, you must contemplate the usefulness of all that research—whether it’s actually useful or simply a method for some people to get their name on a piece of paper.

Some of the attacks require physical access to the system. In some cases, you must actually take the system apart to access components in order to perform the security trick. Unless you or your organization is in the habit of allowing perfect strangers physical access to your systems, which might include taking them apart, you must wonder whether the security issue is even worth worrying about. You need to ask why someone would take the time to document a security issue that’s nearly impossible to see, much less perform in a real world environment. More importantly, the moment you see that a security issue requires physical access to the device, you can probably stop reading.

You also find attacks that require special equipment to perform. The article, How encryption keys could be stolen by your lunch, discusses one such attack. In fact, the article contains a picture of the special equipment that you must build to perpetrate the attack. It places said equipment into a piece of pita bread, which adds a fanciful twist to something that is already quite odd and pretty much unworkable given that you must be within 50 cm (19.6 in) from the device you want to attack (assuming that the RF transmission conditions are perfect). Except for the interesting attack vector (using a piece of pita bread), you really have to question why anyone would ever perpetrate this attack given that social engineering and a wealth of other attacks require no special equipment, are highly successful, and work from a much longer distance.

Another example of incredibly weird security research is found in the article, When the good guys are wielding the lasers. I have to admit it’s interesting in a James Bond sort of way, but we’re talking about lasers mounted on drones. This attack at least has the advantage of distance (1 km or 0.6 mi). However, you have to wonder just how the laser was able to get a line of sight with the attack object, a printer in this case. If a device is critical enough that someone separates it from the Internet, it’s also quite likely that the device won’t be sitting in front of a window where someone can use a laser to access it.

A few research pieces become more reasonable by discussing outlandish sorts of hacks that could potentially happen after an initial break-in. The hack discussed in Design flaw in Intel chips opens door to rootkits is one of these sorts of hacks. You can’t perpetrate the hack until after breaking into the system some other way, but the break-in has serious consequences once it occurs. Even so, most hackers won’t take the time because they already have everything needed—the hack is overkill.

The articles that help most provide a shot of reality into the decidedly conspiracy-oriented world of security. For example, Evil conspiracy? Nope, everyday cyber insecurity, discusses a series of events that everyone initially thought pointed to a major cyber attack. It turns out that the events occurred at the same time by coincidence. The article author thoughtfully points out some of the reasons that the conspiracy theories seemed a bit out of place at the outset anyway.

It also helps to know the true sources of potential security issues. For example, the articles, In the security world, the good guys aren’t always good and 5 reasons why newer hires are the company’s biggest data security risk, point out the sources you really do need to consider when creating a security plan. These are the sorts of articles that should attract your attention because they describe a security issue that you really should think about. Likewise, reading articles such as, Software developers aren’t implementing encryption correctly and 4 fatal problems with PKI help you understand why your security measures may not always work as well as anticipated.

The point is that you encounter a lot of information out there that doesn’t help you make your system any more secure. It may be interesting if you have the time to read it, but the tactics truly aren’t practical and no hacker is going to use them. Critical thinking skills are your best asset when building your security knowledge. Let me know about your take on security research at John@JohnMuellerBooks.com.

 

Is Bring Your Own Device (BYOD) Going Away?

The Bring Your Own Device (BYOD) phenomena has gone on for a number of years now, but no one really knows for certain how it impacts organizations today. If you read surveys, you might get the idea that BYOD is either exploding or fading. The surveys that readers of Security for Web Developers, HTML5 Programming with JavaScript for Dummies, and CSS3 for Dummies are most likely to read say that BYOD is fading. The problem with those surveys is that they’re taken by IT professionals in large organizations that have an official policy of not allowing the device. Disallowing BYOD doesn’t mean that users actually follow the policy.

In reading other articles, you might be the idea that BYOD is actually exploding. The problem with these articles is that they’re based on supposition, not fact. There is no data to back up the claim that BYOD is becoming more prevalent in the workplace. Therein lies the problem. The only official surveys talk to IT personnel on the record and not to users off the record. No one would admit to using a disallowed device—potentially throwing their job away over the purity of information.

Human nature being what it is, my feeling is that people are probably employing BYOD when they feel they can get away with it. After all, why use multiple devices to perform work when a single device does it all? Users don’t care about hardware, software, data, or anything else for that matter. They care about getting their work done, getting off on time, and getting paid—end of question. Consequently, it makes sense that if users feel that it’s possible to get by using a single device to do everything, they’ll do so. However, I have absolutely no data to back this feeling up and you have to accept my claim for what it is—a feeling.

Something that I’ve been emphasizing in my books is this idea of risk. In order to create applications that work well, yet protect organizational assets, it’s important to assess the risk of every policy and every action. Being overly cautious means that applications will work slowly, lack features, and possibly crash a lot. Users don’t like cautious applications and won’t use them if at all possible. Opening the flood gates is a bad idea too. Yes, the application will run quickly and allow a user to do just about anything, but the user won’t thank you for having to stay extra hours at work to fix problems created by an application that loses data or causes other problems because it doesn’t provide an acceptable level of risk avoidance.

No matter what survey you look at, BYOD is still a presence in the workplace, so you need to write applications in such a manner that they deal with the risks presented by BYOD in a reasonable manner. What this means is checking every bit of data you receive from anywhere for potential risks, but not unnecessarily hobbling the user with policies that really won’t mitigate any risk. Let me know your thoughts on the effects of BYOD in your organization and the actual level of BYOD use at John@JohnMuellerBooks.com.

 

Checking for Mobile Friendliness

I’ve been writing computer books for over 29 years now and some people might think that’s long enough to know everything there is to know about computers. Actually, my involvement with computers spans over 40 years and I haven’t learned everything yet—nor will I. Every day is a new adventure, which is why I keep going. Besides the other projects I’ve been working on (which includes discovering the inner workings of both Near Field Communications, NFC, and machine learning), I’ve also been working through this whole concept of mobile device friendliness. In fact, I’ve discovered that there is actually a difference between sites that are mobile friendly and those that are mobile responsive, in that a mobile responsive design does a lot more for the mobile users (and is always mobile friendly by default).

During the time I wrote HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, the concept of mobile development was still quite new. There weren’t any good tools for testing mobile friendliness. Consequently, both books do try to address the topic to a small extent (the extent possible at the time), but neither book says anything about testing. Fortunately, vendors such as Google are now making it possible for you to verify that your site is mobile friendly with an easy to use check. All you need to do is point your browser to https://www.google.com/webmasters/tools/mobile-friendly/, enter an URL, and click Analyze. You get a quick answer to your question as shown here within a few seconds.

Verify that your site will support mobile users by performing a mobile friendly check.
Output from a Successful Mobile Friendly Check

The page contains more than just a validation of the mobile friendliness of your site. When you scroll down, you see a simulated output of your site when viewed on a smartphone. The view is important because it helps you understand how a mobile user will see your site, versus the view that you provide to desktop and tablet users. It’s important not to assume that mobile users have the same functionality as other users do. Here’s the simulated view for my site.

Mobile users may see something different than you expect, even when your site is mobile friendly.
Verify the Smartphone View of Your Site

As more and more people rely on mobile devices to access the Internet, you need to become more aware of what they’re seeing and whether they can use your site at all. According to most authorities, more users access the Internet using mobile devices today, than other devices, such as laptops, desktops, or tables. If you don’t support mobile devices correctly, you lose out on the potential audience for your site. This means that you may make less money than you otherwise could from sales and that the influence of your site is far less. Let me know your thoughts about mobile device access at John@JohnMuellerBooks.com.

 

Browser Support in My Books

A number of my books rely on browser output to show the result of various coding techniques, including Security for Web Developers, HTML5 Programming with JavaScript for Dummies, and CSS3 for Dummies. I try to keep up with changes in technology with my books and I’m currently testing the code in all three books with Internet Explorer 11. According to a recent ComputerWorld article, users of older version of IE only have six weeks to make an update to the new version. They can also use the Edge browser or move to a competitor’s browser. My books list the browsers I used for initial testing of the source code, but I do try to at least check the code with newer browsers to ensure you have a good reading experience. In this case, the check is critical because I can’t expect you to rely on unsupported software to use my books.

When I originally wrote each of these books, I had at least one technical editor and a number of beta readers checking my code under various conditions to ensure the code would run as advertised on the maximum number of systems. I no longer have the support, so I’m testing these updates on just my systems. If you encounter a problem with the source code of any of these books, please be sure to contact me at John@JohnMuellerBooks.com. Now, here’s the important part. Make absolutely certain to let me know that you’re using a newer browser—one not originally tested in the book so I can handle your query correctly and also provide an update on my blog. Your input will help other readers.

Whenever possible, I encourage readers to use the environment described in the book to write their own code. Doing so reduces the potential for problems because I know that the environment is tested by a number of people in a number of environments. However, sometimes using the original environment isn’t possible any longer, such as this instance where Microsoft is putting its collective foot down and forcing an update. Please be sure to write me if you have any questions about the source code for these book. Thanks, as always, for your continued support!

 

Considering the Authentication of Credit Cards in Web Settings

While I was writing Security for Web Developers I considered a great many security scenarios that web developers (and those who work with them) have to face. It always seems as if the hackers are two steps ahead. Of course, one of the biggest problems is static technology. For example, the Credit Verification Value (CVV), a three or four digit addition to a credit card number, is supposed to help safeguard the credit card. It doesn’t appear as part of the card data accessible through the magnetic strip or the chip. The CVV is actually printed on the card as a separate verification for venues such as web applications. The only problem is that this number is static—it remains the same for however long you own the card. Therefore, once a hacker discovers the CVV, it no longer provides any sort of security to the card owner. Interestingly enough, some sites online will sell you both credit card numbers and their associated CVV. The hackers win again.

A solution to this problem is to change the CVV periodically. Unfortunately, trying to change a printed CVV is impossible without replacing the card. One possible way to overcome this problem involves the addition of an e-paper space on the back of the card that would allow the credit card companies to change the CVV, yet keep it out of the magnetic stripe or chip. A lot of devices currently use e-paper, such as Amazon’s Kindle. The technology provides a matte paper-like appearance that reflects light similar to the way in which paper reflects it, rather than emitting light like an LED does. The difference is that e-paper is often easier to read.

Oberthur, the inventor of the Motion Code technology used to create the updated CVV, isn’t saying too much about how the technology works. There must be an active connection between the card and a server somewhere in order to update the CVV once an hour as specified in the various articles on the topic. The only problem is in understanding how the update takes place. If the technology relies on something like a Wi-Fi or cell connection, it won’t work in rural areas where these connections aren’t available. Even so, the technology does promise to reduce the amount of fraud that currently occurs—at least, until hackers find a way to thwart it.

What is your feeling about credit card data protection? Does Motion Code technology actually provide a promising solution or is it another dead end? How do you deal with potential fraud when creating your applications? Send  your ideas to me at John@JohnMuellerBooks.com.

 

Web Apps and Outdated Software

A particular problem that developers face when creating web apps is that users are notoriously lax in updating their software. A problem piece of software may make it easy for a hacker to gain access to the system. In some cases, the user will blame your application because it depends on software that could be outdated on the user’s system. A recent InfoWorld article, 10 old, risky applications you should stop using, brings the issue to light. Many of these pieces of software see use in Web apps. You may think that the user will rely on the newest version of the software, but the user may, in fact, have a piece of software that’s several generations old, yet runs your web app just fine.

Most of my web development books at least hint at the issue of dealing with outdated libraries, APIs, and microservices. Security for Web Developers makes the strongest case for verifying that web apps rely on the latest third party products to ensure the web app is less likely to cause a security breach, but both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies discuss the issue as well. The point is that you need to know that a user is relying on the latest software if at all possible. Otherwise, you may find your web app blamed for a security breach actually caused by another piece of software, such as a web browser.

The fear that many users have is that your web app will stop working if they upgrade to newer software. This fear has a strong foundation in broken applications of all sorts in the past. The problem can become quite severe. Looking at the InfoWorld article, you find several interesting bits of information. For example, many existing applications rely on Microsoft XML Core Services 4.x, despite the fact that the software is no longer supported and represents a huge security hole that hackers are only too happy to exploit. If the user removes this software to keep their systems safe, they may also have to give up on one or more mission critical applications. Testing is the developer’s tool of choice in this case. Make sure you test your web apps with the lasted software and then publish the results online. Keep users informed of potential problems and your plan for fixing them so that they can continue making required updates to keep their systems safe.

It may not be entirely possibly to fix every security problem immediately. The fact is that software today is so interdependent on every other piece of software that even when your web app has fully supported underpinnings, the software you depend upon may not. The dependencies cascade in convoluted ways that make it entirely possible that a hacker will find a way to breach your application despite your best efforts. Consequently, you not only need to maintain a firm grasp on testing, but also of potential problems with the software used to reduce your development effort and make the application perform better. In short, you need to have a contingency plan in place for those times when a hacker finds a way to break your web app because a determined hacker will fine a way.

Outdated software is the bane of developers everywhere, yet users remain clueless as to how much damage they invite by not making required updates. One of the issues that I’m constantly striving to solve in my books is this whole concept of software dependency and how it affects application reliability, security, and speed. If you find that some of the materials I’ve put together are especially helpful (or possibly not helpful enough), please let me know about them at John@JohnMuellerBooks.com. I want to be sure that the security features of my books really do help you past the whole outdated software issue because users really won’t be much help at all.

 

Web Security, A Lot More Complicated Than It Seems

I recently finished writing Security for Web Developers. During the months that I worked on the book, I became aware of a serious problem in the reporting, handling, and supposed fixes for the problem of web security—everyone seems intent on making things fast and easy. Depending on the source, you also see a fair amount of finger pointing at play. Sources put the blame on just one or two entities in most cases. Unfortunately, the picture is far more complex than simply applying a bandage to one or two potential security problem sources. I started understanding the problem when I wrote HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, but it wasn’t until I wrote this book that I began to understand the true enormity of the problem. It isn’t just one or two or three sources—it’s all the sources combined. In this latest book I explore a lot of different sources of security problems and provide advice on how to overcome these issues to some extent.

  • Users
  • Application Developers
  • Third Party Library, API, and Microservice Providers
  • Administrators and Other IT Staff
  • Product Distributors
  • Data Service Providers

Many other groups appear in the book as well. The more I dug, the more I found that just fixing one problem or educating one group wouldn’t solve anything. Hackers look for easy ways to gain access to applications and the current system provides them with plenty of opportunities. The current strategy of responding to just one potential threat will continue to fail simply because the hacker will move on to another threat. Unless an organization is willing to take a holistic approach to security, hackers will continue to enjoy overwhelming success without a whole lot of work. In writing Security for Web Developers, I attempted to provide a broader view of the security picture so that development teams that include all of the stakeholders involved in an application effort can finally work together to resolve the security issues in their individual areas of expertise (including users who are susceptible to too many kinds of attack to mention).

A reader recently asked me whether the strategies in my book will prevent attacks, which is a loaded question and one that is hard to answer. My view of security is that a determined hacker will always gain entrance to your system, so you must remain vigilant at all times. If someone wants your data, they’ll gain access, but if you’re equally vigilant, you can keep the damage to a minimum. For that matter, you might be able to prevent any real damage. However, you need to realize that no security measure you take is going to succeed all the time.

What my book does is help make your system less appealing. In other words, if a hacker is just looking for a system to invade and not specifically your system, then making your system less appealing will see the hacker move to other systems. Like anyone else, a hacker seeks to minimize effort and maximize gain. Making your system less appealing by employing a holistic security approach will increase the effort the hacker must employ and make it less likely that the hacker will continue probing.

Unless you really want to see your organization’s name join the victim list in the trade press, you really do need to employ security across an organization, which means vetting software fully, educating users, having appropriate policies in place, reviewing software before placing it in production, and so on. Using just one or two measures simply won’t work. Let me know if you have questions regarding my upcoming book at John@JohnMuellerBooks.com.