Rob Kraft's Software Development Blog

Software Development Insights

Archive for October, 2012

Software Project Management Challenge #1

Posted by robkraft on October 30, 2012

The software programmer has added a feature to the program as requested but the feature contains a minor flaw.  The programmer has spent four hours trying to eliminate the flaw with no success.  As shown in the images, the flaw is a visual flaw.  When the screen is resized to a smaller size, one of the input fields vanishes.  But any subsequent resize causes the missing field to re-appear.


Should the programmer continue to fix the flaw?  None of the programmers has any ideas for how to fix the flaw, they have already researched and tried everything they can think of.  No time estimate can be made for the fix; it might take 2 hours or it might be impossible to fix.

Your software has 5,000 users, but you estimate this feature will be used about once per day by 10 of those users on average, and if those users don’t resize the screen they won’t notice a problem.

  1. Do you have the programmer continue to work on the flaw for 8 hours and then re-assess the issue.
  2. Do you have the programmer spend 40 hours redeveloping the feature completely in a different way that hopefully will have no problems.
  3. Do you remove the feature from the code hoping to try to implement it again in a future iteration?
  4. Do you create a new ticket in the bug tracking system to address the problem in the future, or do you leave it unrecorded and hope it is never reported.
  5. If you create a new ticket in the bug tracking system, do you include the bug in the list of known bugs in the application?
  6. Do you tell your quality assurance team to ignore the bug; to not report it as a bug.

This challenge is typical of the decisions that need to be made every day in software development.  I don’t believe there is a correct or best answer to this scenario.  Perhaps you have a junior programmer doing the work and you feel it would be good for him to spend a few days trying to resolve the problem.  Or, perhaps the project is behind schedule and you have several more valuable features to complete so you decide to leave this one as is.  Or perhaps you software has been critiqued severely lately for releasing code with bugs so you decide it best to take this feature out to reduce further stains on your reputation.  There are many factors that go into making this decision and I’m sure I cannot think of all of them.  Can you?


Posted in Project Management | 1 Comment »

There are no I.T. Projects, only Business Projects

Posted by robkraft on October 28, 2012

Businesses often turn to software and computers to solve problems and gain a competitive edge.  When this occurs, both the business analysts and the I.T. staff have a solution in mind that requires computing technology and software.  Sometimes though, non-technical solutions solve problems better and with far less expense.  One current classic example is the use of a white board to track the project of work being done during a software development iteration.  That white board does not need to be electronic, so don’t spend weeks or months creating the white board software especially when all interested parties are located in the same office or room.

Keep in mind these three principles:

  • Can we try out the new process or idea manually, with minimal investment, without spending the time to develop the idea using software.  If we feel the process still requires automation after a few months, can we at least learn some of the requirements from performing the process manually in the first few months.
  • Is the cost of developing the software the best use of our scarce resources?  If purchasing a software solution, is the cost of the purchase worth the investment?  Many companies spend a lot of resources developing software that is not part of their core business.  Doing so is depriving your business of the resources it could be using to better the products that really drive the business.
  • Just because your software developers are busy does not mean you are making progress.  I once learned of a doctor that traveled an hour between two hospitals.  He saw four patients a day because he spent four hours traveling back and forth.  The doctor was constantly busy, but the doctor was not near as productive as he could have been.  Once the doctor changed the schedule of the patients to meet all the patients at one hospital in the morning, and all the patients at the other hospital in the afternoon, the doctor was able to see twice as many patients each day.

Posted in Process, Project Management | Leave a Comment »

How to POST to a REST API using Fiddler

Posted by robkraft on October 24, 2012

Posting to a REST API using Fiddler is very simple, as long as you fill out all the required values correctly. I spent more than an hour figuring out the correct info for my REST API recently so I am documenting it here for my own sake, and hopefully to speed the resolution for others. The URL shown in the image is not real, so don’t expect that URL to work for yourself.

  1. Select the Composer tab in Fiddler.
  2. Select POST from the dropdown.
  3. Enter the URL of the REST API. My REST API had a .svc extension, but most REST APIs do not.
  4. In the Request Headers, include “Content-Type: text/xml”. This is the step I missed that took me so long to resolve. Your REST API may not need this, but the REST API I was working with developing on the Microsoft Stack did. You do not need to provide the values for Host or Content-Length in your Request Headers because Fiddler will populate those for you.
  5. In the Request Body, provide the XML or Json data that you are sending to the URL as part of the POST.
  6. Click on the Execute button.
  7. Check the panel on the left (not shown in the image) to see the result of your API call. For my API, the POST returned a 200 and the Response Body contained my response data.

That’s it. Good Luck!

How to POST to a REST API using Fiddler

Posted in CodeProject, Coding, Free tools | 7 Comments »

Use BCrypt to Hash Your Passwords: Example for C# and SQL Server

Posted by robkraft on October 9, 2012

By now you know passwords should be stored using a hash.  Given your decision to do the right thing and hash your passwords you still have to decide some implementation details.

First, choose a hashing algorithm.  Choose BCrypt.  Why BCrypt?  I’ll give you two reasons:

  1. It is slow, and slow is good because it thwarts brute-force attacks (read more here:
  2. The output from BCrypt is a Base-64 alphabet ( which means there are no characters that are tricksy to store in a simple character field; CodePage is irrelevant.

Second, find a reliable implementation of BCrypt.  I am going to show an example of using C#.Net and SQL Server, but here is a good reference I found using  PHP and MySQL (  I also say a “reliable implementation” because there are flaws in some implementations, such as one discovered in 2011 and discussed in these articles ( (Search for $2y$) in this second article. – $2y$ indicates you are using a version of BCrypt for Unix that does not contain this bug).

I am using Derek Slager’s C# implementation of BCrypt downloaded from here:  Based on a little testing I did myself, I believe it does not contain the flaw cited in the above article, but I am no expert at this.  Even if the bug discovered in 2011 exists in this implementation of BCrypt, it is of little concern to me as all of my users are located within the U.S. and are extremely unlikely to be using password characters that cannot be directly entered from a standard keyboard (characters with ASCII values greater than 127).  And even if a user does have such a password, the attack vector remains incredibly tiny for exploitation.

Third, understand the inputs and outputs.  BCrypt includes a method to generate a salt.  When the salt is applied to the password, the resulting hash holds the original salt and the hashed password.  You can store the salt and password combined in a CHAR(60) field in your database.  You don’t need to store the hashed password separately from the salt, nor should you, since the BCrypt class contains a method that expects the salt and password combined to be passed in as a parameter when later confirming the correctness of the user-entered password.

Note, the salt always begins with something like $2a$10$ meaning version 2a of BCrypt and 10 rounds of computations.  10 rounds is the default.  You can choose larger numbers to make it slower, or smaller numbers to make it faster, but 10 is a really good choice for most of us.  Since the rest of the salt is 22 bytes, and the $2a$10$ is 7 bytes for a total of 29 bytes, the hashed password is always the remaining 31 bytes.  The total length of the output that you will store in the database is always 60 bytes long.

string myPassword = "password";<br>
string mySalt = BCrypt.GenerateSalt();<br>
//mySalt == "$2a$10$rBV2JDeWW3.vKyeQcM8fFO"<br>
string myHash = BCrypt.HashPassword(myPassword, mySalt);<br>
//myHash == "$2a$10$rBV2JDeWW3.vKyeQcM8fFO4777l4bVeQgDL6VIkxqlzQ7TCalQvla"<br>
bool doesPasswordMatch = BCrypt.CheckPassword(myPassword, myHash);<br>

Each password stored will have a different salt, and every time a user changes their password you will generate a new salt for the user.  I also encourage you to add a little hard-coded salt to the password.  This hard-coded salt adds a little more challenge to brute force attacks from hackers that steal your database, but have not stolen your code and don’t have the hard-coded salt.

private void SetPassword(string user, string userPassword)<br>
   string pwdToHash = userPassword + "^Y8~JJ"; // ^Y8~JJ is my hard-coded salt<br>
   string hashToStoreInDatabase = BCrypt.HashPassword(pwdToHash, BCrypt.GenerateSalt());<br>
   using (SqlConnection sqlConn = new System.Data.SqlClient.SqlConnection(...)<br>
     SqlCommand cmSql = sqlConn.CreateCommand();<br>
     cmSql.CommandText = "UPDATE LOGINS SET PASSWORD=@parm1 WHERE USERNAME=@parm2";<br>
     cmSql.Parameters.Add("@parm1", SqlDbType.Char);<br>
     cmSql.Parameters.Add("@parm2", SqlDbType.VarChar);<br>
     cmSql.Parameters["@parm1"].Value = hashToStoreInDatabase;<br>
     cmSql.Parameters["@parm2"].Value = user;<br>
<p>private bool DoesPasswordMatch(string hashedPwdFromDatabase, string userEnteredPassword)<br>
    return BCrypt.CheckPassword(userEnteredPassword + "^Y8~JJ", hashedPwdFromDatabase);<br>

Another reference to BCrypt compared to SHA512:

Update for 2022: Some algorithms are now better than BCrypt because they are more difficult (take more time) to brute-force crack. Argon2 is the best, and PBKDF2 is also really good. However, only PBKDF2 is in .Net Core (or so I’ve read), and if you find an Argon2 library on github (or elsewhere), you have to decide for yourself if it is trustworthy and correctly implmeneted.

Posted in Code Design, CodeProject | 4 Comments »