Robotics Parts and Information

Local Vendors

I used to get my electronics parts from a number of brick and mortar stores as Radio Shack (no longer in operation), Lafayette Radio Electronics (went out of business many years ago), and some stores specializing in amateur radio equipment.  However, I have found it difficult to find brick and mortar stores in the Philadelphia, PA area.

MicroCenter in Wayne, Pennsylvania has a number of robotics and electronics parts.  They carry starter kits for the Arduino and Raspberry Pi, which are good places to start experimenting with these technologies.  However, I have found the organization of this section of the store to be confusing, and it is hard to find things.

Electronics Suppliers

It now appears that I am going to have to get most of the supplies by ordering over the internet.  The firms listed here carry a wide variety of electronic parts. In addition, a list of suppliers can be found at  There is also a blog entry comparing some of the vendors at

If anyone has information on ordering from these firms, I would like to add it to the listing.  I would especially be interested in minimum purchase and shipping charges, since many people only need a small part or two to complete a project. This list is merely intended as a list of references that I have found in various pieces of literature.  No endorsement of statement of quality is intended.

  1. All Electronics
  2. Allied Electronics
  3. Arrow Electronics
  4. Avnet
  5. Digi-Key Electronics
  6. Hammond Manufacturing – Enclosures and Transformers
  7. Jameco Electronics – Five dollar processing fee for orders less than twenty five dollars (fifteen dollars for web orders).  Shipping via UPS, FedEx, or USPS.
  8. Markertek – The selection here is designed for broadcast and audio-video operators.  Because of this, the selection of parts is somewhat different from the other vendors.
  9. Mouser Electronics – No minimum purchase for normally stocked parts with shipping via UPS, FedEx, or USPS.
  10. Newark – also Newark Electronics and
    Newark Element14™

Robotics Oriented Vendors

These are companies that specialize in DIY robotics and electronics.  Many of them have educational sections, blogs, and forums as part of their website.  This is merely intended as a list of references that I have found in various pieces of literature.  No endorsement of statement of quality is intended.

  1. Actobotics  – When I went to MicroCenter, I found a number of robotic parts that were listed under the brand name Actobotics.  Some of these are now found on the ServoCity website but without the Actobotics branding.  (The Actobotics branding still appears in some of the videos.)  The trademark was apparently sold to SparkFun, with the web page being located at   Actobotics is now apparently a set of modular parts for building robot chassis.
  2. AdaFruit   – The items sold on this web site are mainly designed for the Raspberry Pi microcomputer, although there are a few items for the Arduino microcontroller.
  3. Arduino  This is the official site for information on the Arduino microcontroller.  This is a very low cost microcontroller that is designed for a very small form factor and it can be embedded in DIY projects.
  4. Evil Mad Scientist – With a name like this, you can tell that they don’t take things too seriously.
  5. OSepp – Appears to be mainly oriented towards Arduino.  Many of their products are carried at MicroCenter and mail order distributors.
  6. Pololu – A number of robotics kits.
  7. Raspberry Pi – This is the official site for the Raspberry Pi.  The Raspberry Pi is a low cost UNIX microcomputer and is designed for a very small form factor that can be embedded in DIY projects.
  8. RobotShop
  9. ServoCity – They have a large selection of servos and motors for use in robots.  Some of the Actobatics robot kits are now listed on the ServoCity website, but without the Actobatics branding.  (The Actobotics brand name is still visible in some of the videos.)
  10. Solarbotics – A number of robotics kits and parts.
  11. Sparkfun   – Robotics kits and parts.
  12. Technologic Systems – This appears to be another source of embedded computers.  I’m not sure how useful it would be for robotics and electronics hobbyists.
  13. Tinkersphere – They have a brick and mortar store in New York City at 152 Allen Street, although they also sell online.  Now that there is no more Radio Row in Manhattan, this might be worth looking at if you are visiting the city.
  14. Velleman – Although their main site is at, the American site is at  MicroCenter carries a number of items from this company as do many of the mail order firms in the USA..

Fixing the Cellebrite/GrayKey Hack


, , , ,

According to an article by Thomas Brewster on the Forbes website, it appears that Apple has closed the vulnerability on the iPhone used by the GrayKey unlocking tool.  However, what I have seen would seem to indicate that Apple is being deceptive about how they blocked the exploit.  Normally, I approve of deception in this regard, but I am also unable to determine whether the problem has been completely rectified.

  • Apple claimed that the USB Restricted Mode was what resolved the problem.  However, several organizations indicated that they had workarounds for this mode.  It would also seem that there are many circumstances where a phone could be seized within minutes of the lock screen appearing.  For example, seizure at customs inspection points and airplane boarding.  (See Bradley Ross, “Failure by Apple to Stop iPhone Unlock Exploit”.)
  • When I looked at the information on the exploit (Bradley Ross, “Analyzing a Hack”), it appeared that there was a better than even chance that the problem could be resolved by incrementing the pointer before testing the passcode.  There was also a similar problem with an earlier version of iOS, and it appears that the problem was only fixed for that specific instance as opposed to looking for similar situations.  I still don’t know if there was a search for similar situations.  Fixing a bug is not sufficient, you need to fix all instances of that class of vulnerability.
  • The articles on the exploit being blocked appear to be based on the one article by Thomas Brewster.  Having only one source makes it difficult to trust information.
  • As I said before, it is possible that Apple has corrected the vulnerability, but it does not appear that it was done in the way described in Apple.  More transparency would help in evaluation of the potential security problems.

What I would really like to see would be some of the following.

  • A statement from a different source that the problem has been resolved.  (I realize that others are searching for ways to work around Apple’s patch, and this would only be correct at this time.)
  • A statement on how to prevent this vulnerability in other programs or platforms.  This is not the same as saying how Apple fixed it.  It is quite possible to list a number of topics without mentioning which were used for this specific patch.  To quote the musical “Hello, Dolly”, techniques for eliminating vulnerabilities “are like manure.  They only work if you spread them around.”


Failure by Apple to Stop iPhone Unlock Exploit


, , , , ,

Cellebrite and GrayShift (GrayShift’s product is named GrayKey) have been selling their services for unlocking iPhones despite seeting the phone to delete data after ten failed login attempts. Since these companies apparently use the USB connection to run the exploit, Apple has inserted code (USB Restricted Mode) that will prevent data transfer via USB if the phone is locked and the phone has not been unlocked within the past hour. (For more information, see my previous blog entry.)

A least, that’s how it’s supposed to work. Even before the USB Restricted Mode was implemented in beta versions of the operating system, several people were saying that they already had updates ready that would enable their exploits to continue working. Personally, I thought that USB Restricted Mode would never be effective for the following reasons.

  • The real problem is that it is possible to test passcodes without incrementing the counters in the SEP (Secure Enclave Processor). This is not addressed in the press releases from Apple, and there is no indication that they are aware of the underlying cause. Unless you can identify the root cause of this vulnerability, it is impossible to determine all the ways that this vulnerability can be exploited.
  • USB Restricted Mode only addresses one method of exploiting the vulnerability. I suspect that there is a high probability that any vulnerability that can be exploited using items attached via USB can also be exploited via Bluetooth, WiFi, and malicious applications being introduced in the iOS App Store.
  • The chances that the phone has been unlocked in the past hour is actually very high. People seem to find it very hard to keep from using their iPhone for more than an hour at a time. A malicious actor could also wait until the user has accessed the phone and then steal it within fifteeen minutes.

As I stated in the previous blog entry, there is a strong possibility that the exploit can be thwarted by simply incrementing the counter of failed login attempts before testing the passcode. Whatever the case, it would appear unreasonable to declare fix without getting to the underlying flaw. It almost seems like Apple is denying the existence of an underlying flaw that can be exploited.


“New IOS Security Feature Ripe for Defeat”,, 21-August,2018,

Bradley Ross, “Analyzing a Hack”, Bradley Ross’s Blog on Life and Computer Software, 16-June-2018, – This is my previous blog entry on this topic.

“Grayshift claims it defeated Apple’s forthcoming ‘USB Restricted Mode’ security feature”, AppleInsider, 14-June-2018,

Joseph Cox and Lorenzo Franceschi-Bicchierai, “Cops Are Confident iPhone Hackers Have Found a Workaround to Apple’s New Security Feature”, Vice Motherboard, 14-June-2018,

Thomas Fox-Brewster, “Apple iOS Security Boost Not Stopping Cops Hacking iPhones”, Forbes26-July, 2018,

Vladimir Katalov, “USB Restricted Mode Inside Out”, ElcomSoft, 12-July-2018,

Oleg Afonin, “This $39 Device Can Defeat iOS USB Restricted Mode”, ElcomSoft Blog, 9-July-2018,

Analyzing a Hack


, , ,

There has been a lot of discussion on the internet recently on the ability of an attacker to test unlimited numbers of PIN/Passcode values without triggering the auto-delete function puilt into the iPhones. So I have put together this article to show a means of looking at such a problem logically.

Determining Probable Location of Vulnerability

The exploit involves testing more than ten possible passwords without triggering the erasure of data on the phone. According to the Apple literature, this would not be possible without flaws in the hardware, firmware, or software in the Secure Enclave Processor (SEP). There may be flaws in other parts of the phone that enable the flaw in the SEP to be exploited, but the exploits described involving Cellebrite, GrayKey, and others require flaws in the SEP that violate the postulates that make up the requirements for the SEP. Some of these postulates are as follows.

  • It is not feasible to remove the cover of the chip carrier containing the SEP and inserting probes to access or modify data without triggering the erasure. The description of several of the exploits state that the case and chip carriers are not opened or modified.
  • Key pieces of persistent data contained in the SEP can’t be read or written using the pins for the chip carrier without going through the software in the SEP.
  • There are certain “salt” values that are set during the manufacture of the device and stored in persistent memory in the SEP. Output data lines for memory containing this information only connects to the cryptographic portion of the chip and not by the general purpose CPU in the SEP. It is not possible to read operating system, firmware, or other files without using the cryptographic portion of the chip.
  • Certain variables, such as the number of consecutive unsuccessful login attempts and the time of the last unsuccessful login attempt are considered extremely critical. They should only be accessible by the SEP firmware and the code in the firmware capable of reading and/or writing this information has been subjected to additional review.

Web Search

The first step in analyzing anything is generally research. So I spent a little time on the internet using Google to search for relevant articles. Some combinations that will work well with Google are the following.

  • ios unlock tool
  • “ios 11” unlock tool
  • iphone crack passcode

When you use something like Google Search, it isn’t enough to just look at the first few entries. It is necessary to go through pages of listings and then try new searches based on the items you find.

Relevent Events

Based on the Google search, I found that the relevant literature seemed to fall within a few categories. I have listed them below in chronological order.

  1. Apple CVE-2014-4451 This was an exploit that allowed users to try an unlimited number of PIN codes. The articles were dated November 18, 2014, and the vulnerability was reported detected and resolved within the development of iOS 8.
  2. Secure Enclave Processor Decryption – Articles published on August 17, 2017 indicate that the decryption key for the Secure Enclave Processor had been published. This means that an attacker could reverse compile the SEP code to learn how it works.
  3. Chinese Cracker Box – This is a cracker box (reportedly from China) that will crack the PIN code on the latest iPhones. The articles were dated August 17, 2017. I am simply referring to it as the “Chinese Cracker Box” for convenience. The cracker community is not necessarily known for “truth in labeling”.
  4. GrayKey Cracker Box – GrayKey is a cracker device manufactured by GrayShift. The articles state that information on the device first appeared in late 2017.
  5. Cellebrite Exploit – Celebrite provides much less information than the others, but a number of articles in February and March 2018 indicate claims that Cellebrite has developed mean of unlocking the latest iPhones.It appears that development of this technique was in late 2017 since one of the articles stated that it was developed in the last few months.

A review of the dates seems to indicate a few connections between the problems.

  • Reports on the decryption of the Secure Enclave Processor (SEP) and the Chinese Cracker Box appeared at the same time. This was a few years after CVE-201404451.
  • Usage of CVE-2014-4451, the Chinese Cracker Box, and the GrayKey device appear to interrupt a process after a passcode is tested, but before the counter for unsucessful login attempts is incremented.
  • The GrayKey and Cellebrite cracks appear to have been developed at about the same time and development was after
    the Chinese Cracker Box.


Scientific analysis first requires observation and research. The next step is to create a hypothesis. Let us consider the following as a hypothesis.

  1. Assume that a person interested in studying vulnerabilities on the iPhone has been collecting iPhones after each update. That would seem reasonable given the amount of money being spent.
  2. After the firmware decryption key was determined, it would be possible to reverse compile the SEP code before and after CVE-2014-4451 was resolved.
  3. Comparing the two versions of the SEP code would enable the researcher to find the section of code that waschanged to remove the vulnerability.
  4. (This step is a wild-ass guess.) The fix may have been to move the incrementing of the counter before the test of the trial password. After all, a successful login will reset the counter, so the overall logic would remain unchanged.
  5. You would then examine the current version for other places where the same erroneous code appears. (e.g., other locations where the password is tested before incrementing the counter.) Each of these locations would then be checked against the exploit in CVE-2014-4451 to see if any of them could be exploited.
  6. The Chinese Cracker Box would then be developed using the newly found vulnerability. Sales of the device took place by August, 2017.
  7. The release of the firmware decryption key came from someone who had access to the development of the Chinese Cracker Box. This is based on the fact that both items were reported at the same time.
  8. Since the Chinese Cracker Box was available on the underground market, both GrayKey and Cellebrite would likely have purchased copies of the unit. Four months sounds like a reasonable development time for them to implement their “new and improved” versions.

Human Behavior

I have seen many cases where a maintainer will fix one occurence of a bug but not look for other occurences. In fact many times, the word from management is “Just fix this bug and close out the task. Don’t waste time.” I have heard this expressed very frequently and very forcefully.

Since the potential hackers can now reverse compile the code on the SEP, it would be only logical for them to determine the coding changes that fixed earlier problems and then look for other occurrences of the incorrect logic. In this case, a good method would be to look for all code that can change the value of the counter, a task well within the capability of many IDE’s (Integrated Development Environment) or even the UNIX grep command.

Another problem that I have seen is that nobody seems to use fault trees or coverage charts. This is an attempt to use formal logic to determine items that need to be examined. Many consider it too much work to through all the possibilities, and state that it’s good enough. People keep telling me “Don’t worry. It’s good enough”. My experience in these cases is that it’s almost never good enough and I worry a lot. However, this will covered in more detail in a future post.


I have divided the references according to the events that they describe.

Apple CVE-2014-4451

Decryption of Secure Enclave Processor

Chinese Cracker Box

GrayKey Device

Cellebrite Exploit

Secure Enclave Processor

System Architecture and Patching

I was just watching some videos today and they were emphasizing how important it was to install patches immediately.  Unfortunately, when dealing with reality, there are some problems with this.  Fortunately, appropriate system architecture provides methods for dealing with the problems.

Requirement for Testing

The problem with automatically installing patches is that you should test patches before installing them on production systems.  I once worked with an organization that didn’t install any patch from a vendor until it was six months old.  In some cases, patches were replaced after a few weeks because errors were sometimes found and this policy sounds reasonable when you first see it.  However, the vendor was infamous for providing patches that patched earlier patches without indicating which patches they were patching.  When I contacted the vendor’s help desk about a problem, he informed me (with a straight face) that he had never heard of his company’s patches causing problems.  So I knew which patch caused the problem, which patch patched the patch and solved the problem, and the nature of the problem.  I couldn’t get the IT department to install the fix, since I couldn’t get documentation from the vendor and they stated that they wouldn’t install the fix for six months.

Danger of Installing Patches

So you end up with a situation where people don’t trust the patches, but management won’t let you spend the time to test the fix, and you receive the blame from everyone. So if a vendor wants people to automatically install patches, the vendor needs to provide better quality patches, better documentation for the patches, and honest answers from the help desk.

I’m not going to give the name of the vendor.  I know of a number of vendors who have bad reputations in this regard.  So pick the vendor of your choice to fill in the blank.

Can’t Wait For Patches

The next problem is that you can’t assume that all problems will be identified and patched before malicious actors learn of them.  After all, that is the definition of “zero day” vulnerabilities.  This means that installing patches immediately won’t necessarily stop your system from being breached.

The Solution

If you don’t install patches, you will be hacked.  If you install patches, you may still be hacked.  The solution is to assume that one of the components (either hardware or software) in your system contain bugs which create vulnerabilities for malicious parties.  You then organize the system such that a lack of security in one component will not compromise the entire system.

Although the standard approach to single points of failure is to add redundancy, this is not always feasible or appropriate.  Adding redundancy also adds more components that can fail.  You actually have to think about your design of the system to insure reliability and security.  There is no simple way to achieve total reliability, and it probably won’t be cheap.

The following are some things you might want to consider:

  • Have a simplified version of the system with reduced capabilities that that can be activated if problems are detected with the main system.
  • Have monitoring systems that will indicate the existence of improper signals and take appropriate action.
  • Divide the system into multiple components with strictly defined interfaces.  This can prevent faults in one component from causing failures in other systems.  If you can identify the most security sensitive components, you can spend more effort on making those components secure.  If you can reduce the complexity of the security sensitive, it will be easier to make those areas secure.
  • If the system depends on passcodes for its security, design the system with the assumption that the attacker knows all of the code and all of the passcodes that are known or accessible by human beings.  It may not be possible to design a system that will fully meet this criteria, but you will surprised how close you can come.


“Single point of failure”, Wikipedia,

“Super Bowl Blackout Caused by Device Installed to Prevent Power Outage”, CBS News, February 8, 2013.

Irrationally Increasing the Load

Laser Printers

Many years ago, I was in an IT group that purchased dozens of Hewlett-Packard LaserJet II printers for internal use.  The problem was that the printers were designed for a maximum of 3000 pages a month and we were using them to generate 2000 pages a day.  They overheated so badly that the rollers inside were melting.  Management was complaining about shoddy workmanship by Hewlett Packard and the partially melted rollers were causing black streaks on the paper.  To get this throughput, we were using third party page feeders that would hold one thousand pieces of paper instead of the standard 100 page trays.  (HP informed us that any use of these giant page feeders voided all warranties and service contracts.)


Expecting a printer designed for 3000 pages a month to be able to produce 60,000 pages a month was not reasonable or rational.  It certainly wasn’t a sign of shoddy workmanship on the part of Hewlett-Packard.  There was a larger model (LaserJet 2000) that would handle the load, but management didn’t want to spend the money.  Given that the LaserJet 2000 had 2.5 times the speed and would have had much lower maintenance costs, it probably would have been better to buy the faster printers at the higher price.

Since the printers were producing more than an order of magnitude over what they were designed for, complaining about the workmanship was hardly rational, but it did provide a means for management to argue why they weren’t at fault.



Just Get It For Me

The Request

Many years ago, I had a manager who was unhappy with the number of facsimile messages he could send and receive each day.  He therefore instructed me to obtain a facsimile machine that was four times as fast.  Unfortunately the rate of receiving and transmitting facsimile messages was set by an international standard.  Limited increases in speed were possible, but the data was transmitted at the speed of the slower machine.

This meant that I couldn’t get a machine that would reliably send and receive pages at four times the rate.  However, I could place four facsimile machines on the same telephone number.  This meant that they could all be sending or receiving messages at the same time, enabling us to process four times as many messages in a single day.


I was told that I had a lousy attitude.  I should simply go and order what he wanted, and he didn’t want to hear any complaints.  The fact that what he wanted was unavailable was irrelevant.  The result was that he didn’t get either the electronic device or the business capability he desired.  (However, I could have easily supplied him with the desired capability.)

Saying what you need to be able to do is reasonable and logical.  Refusing to listen to the other person about how that need can be satisfied is not reasonable.  If he didn’t have the knowledge and skills to satisfy that need, why are you going to him?


Myers-Brigg Classifications

Logical Thinking and Gut Feeling

The Myers Briggs Type Indicator (MTBI) was designed to indicate the personality type of an individual. One of the ways of expressing the personality was Thinking (T) versus Feeling (F). In this case, “thinking” referred to making decisions with dispassionate logic as opposed to your gut feeling.

The company I was at decided to give everyone the Myers-Briggs test and then discuss the results. The department head was very unhappy because he felt he was a totally rational decision maker but the test indicated that he was going by his gut. Despite the fact that all of the other managers agreed with the result, his opinion was unchanged and he even implied that the other managers were lying to him. (By the way, I felt that the test result was accurate.)


  • If you are a “feeling” type and know that you are “feeling” when getting your ideas, you will probably still realize that you have to analyze the results to make sure that it is a good decision.
  • If you are a “thinking” type and know that you are a “thinking” type, you are going to come up with options based on logic.  One of the points to consider logically is to consider how the decision will be viewed by others.
  • If you are a “feeling” type and believe that you are a “thinking” type, you won’t see a reason to evaluate your decision logically.  The fact that you are misreading your own personality means that you aren’t that good at evaluating things, like the difference between emotional and logical arguments.  It also makes it difficult to understand the objections raised by others.

If you don’t understand your own thought processes, you will come up with very bad decisions.  If you don’t see a need to examine ideas logically (The conceit that “I am a genius.  My opinion must be correct.”), the chances for success shrink further.


Tales From the Irrational

Rational vs Emotional

If you look at the various Star Trek television series, you will find that many of them have a character whose primary attribute is being logical and unemotional: Spock on the original series, Data on The Next Generation, Seven of Nine on Voyager, Odo on Deep Space Nine, and T’Pol on Enterprise. In addition to a number of science fiction characters, many detectives in mystery novels, such as Sherlock Holmes and Hercule Poirot, would also seem to fit this archetype.

However, if you look at these characters in their respective stories, you will also see that they have a character who is a mirror image in many ways: more emotional and less logical. For Sherlock Holmes, there was Dr. Watson, while Spock had Dr. McCoy as his verbal sparring partner. The extremely logical characters often appeared slightly inhuman and perhaps a little bit ridiculous. However, they are also the ones who keep the spaceships running, solve the crimes, keep the city infrastructure running, etc. They are often viewed as humorless, but they definitely have a sense of humor, what I call engineering humor.

Their main source of humor is the illogical people they work for. I can assure you that the engineers find the non-engineers hilarious but a little scary. To demonstrate this, I am going to provide a number of scenarios, and you can decide which side seems more like you and which side you would like to resemble. (This may be a spoiler, but I prefer the rational people.)

Classic Example

The classic example of irrational thinking is a old joke about a man who was searching under a lamp post outside a bar.  A policeman walking by asked if he needed any assistance.  Upon learning that the man was looking for his wallet, the policeman asked when he had last seen the wallet and was told that he had last seen it inside the bar.

When the policeman asked why he wasn’t looking for it inside the bar, he was told “The light is much better out here”.

I think that most people would agree that it would have been more rational to search inside the bar, perhaps after asking to borrow a flashlight so that he could see better.  Before laughing at him too much, you might want to review your actions lest you resemble him.  The stories here will helpfully help you in your goal for rational and successful thinking.  (Irrational thinking is rarely successful.)


Auditing Access Attempts

In order to secure your web site, it is necessary to examine requests so that you can detect, report, and respond to attacks on the web site.

Persistent Data

In order to have a secure web site, it is necessary to store the information required for analysis.  Some of the information that will need to be stored for each account are the following pieces.

  • Account name and password
  • Flags indicating the current status of the account, including any red flags raised in the security audit. If access to the account is restricted to specific IP addresses, it will also contain a list of the authorized addresses.
  • Information on each logon attempt, both successful and unsuccessful.  In addition to date and time, this would also contain information on the IP address and port used to send the request, and the result of any validity tests applied to the logon request.

Password Requirements

The first step in planning is to determine the requirements for selecting passwords.  This would include the minimum and maximum lengths, and the characters that can be used in creating the password.  Some systems apply other considerations such as requiring both upper and lower case letters, numeric digits, and punctuation marks.  You have to consider usability, ease of memorization, and difficulty of guessing in determining your rules.

You should also consider creating a list of character strings that can’t be used as passwords, starting with a list of the most commonly used passwords (secret, password, 123456, qwerty, letmein, etc.)   For this purpose, case-insensitive comparisons should be used for rejecting the password, although case-sensitive comparisons will be used for testing whether the password is correct.  You should also reject the password if it is simply followed by a single digit or uses letter number substitutions (LEET speak).  Having “password” on the list should also reject “Password”, “Pa55w0rd”, “PASSWORD1”, “PA55word”, etc.  The reason is only partly to get people to use better passwords.  If you prohibit these passwords, any person using them has a relatively high probability of being an attacker.

Account Restrictions

You may want to have some restrictions on accounts, especially those with administrative privileges.  Some of these restrictions could include the following for specific accounts.

  • Restricting the IP addresses that can be used to access the account.  If a black list can be created of the IP addresses that have been known to launch attacks, the accounts could be set to reject access attempts from these attempts.
  • Require two-factor authentication on some accounts.
  • Some systems have additional information to identify systems that can be used to log on to the account.  This could include cookies, IP addresses, or information maintained by the browser, such as type of browser and operating system.  Adding new systems to the list would require additional confirmation from the user.

Concurrent Analysis

These are the tests that are applied to the request while it is being processed.

  • Since many of the vulnerabilities in web software is based on sending malformed requests, the first step would be to validate the format of the logon request.  If the request is invalid, it is best to return a 500 (Server Internal Error) rather than a 400 (Bad Request) since this gives the least information to an attacker but is still relevant to the problem.
  • The next step would be to make sure that the account name is valid.  If it isn’t, the account name used would be stored in the log of logon requests.  However, the password field in the log would be left blank, although the use of a forbidden password would be noted in the log.  The response to the requestor would be 401 (Unauthorized).
  • If the password is on the forbidden list described above, you should reject the attempt, returning a 401 (Unauthorized) response.
  • At this point, you can test whether the request is coming from a blacklisted IP address.  (The blacklist will be created from the retrospective analysis described in the next section.)  The 401 (Unauthorized) response is often used for blacklisted addresses, but different system administrators have different opinions about which response to use.
  • You can then test if the password supplied in the request matches the one stored in the database.  If it doesn’t, you will return 401 (Unauthorized) response, but also lock out the account for a period of time.  The subsequent requests with the wrong passwords will have gradually increasing time spans, such as 1, 2, 5, 90, and 300 seconds with attempts after the second returning a 500 (Server Internal Error) message with a text stating that the user should try again later.  After the longest lock period (300 seconds in this case) has passed, you can reset the lock out period to the smallest value.

At this point, the user has passed the tests for logging on to the system, and he can gain access.

Retrospective Analysis

Retrospective analyses are carried out by examining the logs for entries over an interval of time.  When attackers try to learn the account names and passwords on a system, they generally use one of two approaches.

  • Go for a specific user and learn all you can about him.  Use that information to guess his password.
  • Obtain a list of account names.  This may involve looking at bulletin boards and e-mails.  You will then try a list of the most common passwords against each of the accounts.  This is known as “account spraying”.  If you only try each account once a week, the chance of being detected is greatly reduced.
  • In “phishing” attacks, you obtain a list of e-mail addresses and send e-mails to each of them.  The e-mails may either contain attachments with malicious payloads or instructions on how to access web sites that contain pages that will corrupt your system.

Account spraying will result in a number of IP addresses having many unsuccessful logon attempts, and few, if any successful attempts. Similar patterns will be found with other types of attacks as well. In addition, it is possible to determine information about an attacker from the IP address. (The amount of information that can be obtained varies according to IP address. If you find a hundred successful logons from the eastern United States, and one successful attempt from Kazakhstan, it would be reasonable to make further inquiries into the person logging in from Kazakhstan.

Additional topics

The following are some additional topics to be discussed in future posts.

  • This is not artificial intelligence.  In fact, the concept of artificial intelligence is so poorly defined that people using the term are usually trying to mislead you or using hyperbole as a sales gimmick.
  • It is possible to identify systems by IP address, cookies, or other means.  If a login attempt is attempted from a new system, you may want to force the user to confirm his identity.  Confirmation may also be desired if a long period of time has elapsed since that system was last used.
  • Confirmation of identity can be carried out by a number of means such as two factor authorization and security questions.
  • You should confirm information when the account is created.  This applies especially to telephone numbers and e-mail addresses.
  • You need to have a policy regarding appropriate actions when penetration of the system is suspected.
  • You need to have a policy describing the actions when a user requests that his password be changed.


  • Security is not always convenient.  During the American Revolutionary War, the British garrison at Fort Ticonderoga left a gate open to make things easier for the cooks and washerwomen to get water and for the guards who would otherwise have to open and secure the gates at frequent intervals.  It did not go well, as the fort was captured before its commander was aware of the attack.
  • If you want to be secure, you will have to make an effort to detect and respond to unauthorized attempts to log on.  Otherwise you are simply leaving the gate open for attacks.
  • Furthermore, being told by your subordinates that the system is secure and you trusted them is not an argument that will go over well with the people you work for.