Archive

Archive for the ‘Security’ Category

The Art of Intrusion: What is a password worth?

May 5, 2011 | Michael Millstein


What is a password worth? A lot…and here’s why you shouldn’t become too attached to just one.

When you think of passwords, what do you think of?

You probably think of your AOL account, gmail, computer log-on, bank account (either online log-on or pin number), online store account…the list goes on. Do you use the same password for every account you have? Chances are you have the same password for nearly every account you have—wait, except with your work account because they make you change your account password every 60 days or so. But, you definitely use a variation of your original password every 60 days, so it’s close enough.

Now, imagine you’re an IT system administrator at Joe’s bank, the largest bank in the nation. Along with the passwords you use on a daily basis for your personal accounts, you also have hundreds of passwords for your Service Accounts, Windows local admin accounts, Root accounts, network devices, etc. What would happen if you used the same practices for work accounts that you do at home? A skilled hacker comes along, figures out your password, and gets the keys to your entire kingdom! And here the stakes are much higher—instead of hacking just one individual’s bank account he could log into your infrastructure and get payroll, social security numbers, credit card numbers, bank account information…everything.

Passwords are among the most valuable information in the world.

The notion that passwords are sacred comes from the book “The Art of Intrusion” by Kevin Mitnick, one of the most famed hackers of all time. The book highlights some of the most memorable hacking attempts in history, some which were successful. One of the stories told could have cost Boeing millions in losses or reputation: two teenagers thought it would be cool to hack for fun. They hacked into Boeing as well as government websites, a credit union, and the DMV among others. They simply used common usernames and passwords. Once they were in they gathered any information they wanted, and browsed wherever they wanted to browse. These young men were just hacking for fun, there was no malice behind their acts but they encountered very sensitive information.

We make our users change their passwords every 60 days or so, but what about all of the privileged accounts mentioned above? Typically, IT pros store their passwords in an encrypted Excel file, use generic/default passwords, and do not change these passwords regularly. Why don’t we enforce the same user-level policies on privileged account passwords? These passwords literally hold the keys to the kingdom yet they are not adequately protected by IT pros. If the passwords are the same across multiple devices and accounts, a hacker can view all the sensitive information on your network without breaking a sweat.

Some companies believe that their strong external firewalls can keep out intruders.

Well think again. Once a hacker gets through that firewall he’ll head straight to your servers, databases and the other accounts containing sensitive information. Without strong internal password policies, or software to help manage passwords and rotate them to keep hackers guessing, your infrastructure is vulnerable. You may be just one hack away from learning a tough lesson. I learned at a recent military event that some of the system administrators for the military and their contractors use Microsoft Access—an unencrypted file—to store privileged account passwords. In addition to not being able to track who has which password, I could have logged on to their system, or hopped onto an unguarded computer, and viewed every sensitive password on the network. This can cause hours, even days in downtime, and millions in expenses. Plus, it can compromise sensitive information that could be devastating to the company concerned, or even the country. “Let’s wake up people. Changing default settings and using strong passwords might stop your business from being victimized” (Mitnick, 88). Don’t be the next victim. Take action and use the same password policies savvy IT administrators place on their end users.

Michael Millstein is an Account Manager at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product.

Secret Server 4.1 goes live!

March 15, 2008 Leave a comment

The team thinks it should be 5.0 since the new features were pretty huge! :)  The full release notes are here.  The new version includes role based security which allows you to slice and dice the access to various features across your organization.  We also have a new feature that allows you to automatically launch Remote Desktop from a secret which is very convenient. 

We have also had interest from many customers about “hardening” their Secret Server installation so there is a new “hardening” report which gives a pass/fail for various features that will make security tighter.  This is really the classic tradeoff between security and convenience.

hardening 

“Simply put, it is possible to have convenience if you want to tolerate insecurity; but if you want security, you must be prepared for inconvenience.”
- General Benjamin W. Chidlaw

 

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products
Take the code test and send your resume along with why you want to join Thycotic to
tddjobs@thycotic.com.

Bad password requirements

January 24, 2008 8 comments

This morning I signed up with a major credit card company website.  Much to my surprise I was greeted with this requirement while choosing a password:

Your Password should contain 6 to 8 characters . at least one letter and one number (not case sensitive), contain no spaces or special characters (e.g. &, >, *, $, @) and be different from your User ID.

Let’s review these limitations:

  • 6-8 characters – Requiring a minimum of 6 seems reasonable but still not very strong.  Capping the length at 8 seems strange since this is still not very strong and why would you want to prevent someone from using a longer (and probably stronger) password?  Unless your database field or legacy systems only support 8 characters …  Does that really mean they are going to store this password in clear text?  Maybe they use some sort of arcane encryption or hashing (hopefully) algorithm that limits the digest size to 8 characters.  Still seems unlikely.
  • At least one letter and one number – This seems like a smart option to force different character sets and improve the password strength.
  • (not case sensitive) – What?!  This reduces the size of the alphabetical character set by half.  This also throws into question whether they are really hashing this password – are there hash algorithms that ignore case?  This requirement makes no sense and definitely feels like a requirement for a legacy system.
  • No spaces – This is a shame since a non-written character like a space can be a great security mechanism especially when at the start or end of a password since it is invisible if the password is ever written down.
  • No … special characters – Why would you explicitly prevent the use of another character set that can greatly improve the strength of the password?  Again this feels like a legacy requirement.

How strong is this password that they are forcing you to use?  I took a look through LockDown’s Numbers and you can easily see how the number of possible combinations for this password is limited by the lack of character sets and case sensitivity.

I am really glad that I used an auto-generated password for this account. :)

Are you hashing and salting passwords in your applications or do you also have bad password requirements?

 

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?

Symmetric Salting – remember that salt goes with more than just hash

November 15, 2007 Leave a comment

If you understand hashing and salting then skip the next paragraph.

Stored passwords for logins should be hashed and salted.  Hashing is a one way mechanism to produce a practically unique value based on the given input.  This is useful since we can store the hash (and validate the password whenever needed) without storing the actual password.  The same input will always produce the same hashed value which is useful for validating password logins but it is also problematic since we could determine that Fred’s password must be the same as Andrew’s password since they have the same hashed value.  This can be taken to an extreme where you roll up the matching hashes across thousands of passwords and can therefore use a common password list to start identifying passwords – think someone looking at your User table with thousands of records looking for hashed passwords with the same value.  The solution is salting which means adding a known random value to each password before hashing it – this makes all the hashed values unique and prevents cross-referencing or dictionary attacks.

If salting is so useful when hashing, shouldn’t we use it for symmetric (two way) encryption too?  Think about this the next time you encrypt lots of data in your application … if someone started looking for identical encrypted values could they deduce things from the data?

withoutsalting

A savvy customer using Secret Server noticed this issue a while back.  We were encrypting the data in Secret Server with strong AES 256 bit encryption but we weren’t salting the values before the encryption.  This meant that the password “foobar” for one secret would have the same encrypted value when saved on another secret.  Our solution was to use a fixed length of random characters (the salt) which we prepend to each value before encrypting it.  This generates unique encrypted values even if the data being encrypted is the same.  When we decrypt the value later, we simply discard the salt.

withsalting

A large salt value can also improve the strength of a small value to be encrypted.  Consider the password “x” – it is one character and can be easily guessed.  However if we prepend it with a 32 character GUID then the value to be encrypted is 33 characters long and presents a greater challenge.  (Note: GUIDs may not be the best choice for your salt since they are hexadecimal and have a smaller character set than a pure alphanumeric).

Remember that the strongest encryption algorithms alone won’t always protect you from attacks so think carefully about your encrypted or hashed data and the possible ways it could be compromised.

 

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?

Shipping Software … Secret Server 3.1 Sneak Peek

July 30, 2007 1 comment

Shipping software is one of the most exciting times for a development team but this new release is easily the most anticipated version of Secret Server to date by our customers. Secret Server 3.1 will feature the two most requested features from customers who visited our booth at TechEd in June 2007: full Active Directory synchronization along with remote password changing. I am very proud of our team being able to take both of these features from whiteboard to release in about 7 weeks.

What this means …

By having the Active Directory add-on, you’ll never have to add another user to Secret Server. All actions made to both users and groups in Active Directory will occur in Secret Server.

The remote password changing feature is perfect for companies that have security compliance guidelines to meet. The administrator sets a date for when the password needs to be changed and once that day is reached, the password will automatically be switched. The remote passwords covered by this feature are Active Directory, Windows and SQL Server accounts. The classic scenario being all those Local Administrator accounts on Windows workstations.

Other key features:

  • Secret expiration – Administrators will be able to set expirations on a Secret Type through the Secret Type Designer.
  • Password history – Secret Server will keep a log on the history of all password changes made to secrets (optional).
  • Enhanced folder options – The folders feature will be enhanced to allow for multiple sub-folders (nested folders). In addition, administrators can set default permissions to folders.
  • Password validation on logins – Administrators will have the ability to customize user login passwords by requiring or restricting special characters, numbers, length, etc.
  • IP Address restriction – Administrators will have the option of setting IP address ranges used for accessing Secret Server.

Secret Server is no longer just a passive repository – we now reach out and interact with other systems in ways we never thought possible.

Find out more about Secret Server here.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is a enterprise password manager system for teams to secure their passwords. Is your team stillstoring passwords in Excel?

Kevin Jones is now an ASP.NET MVP!

April 10, 2007 1 comment

Our own Kevin Jones has been awarded MVP for ASP.NET by Microsoft. This award recognizes his excellence in technical skills and his contributions to the community in spreading best practices in software development.

Kevin has been instrumental in the development of Secret Server since 2.0 and now including Secret Server Online. He has been involved in some fun stuff including SHA512, AES256, symmetric hashing and encrypting Unicode. He has a passion for security and cryptography with lots of great security related posts including his new Security Tips theme on his blog.

Congratulations Kevin!

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is a enterprise password manager system for teams to secure their passwords. Where do you keep your passwords or do you still use the samepassword everywhere?

Secret Server 1.1 makes the Daily Grind

March 28, 2006 3 comments

Mike Gunderloy, one of our early adopters, has
added our
Secret Server 1.1 release to the
Daily Grindtoday!This is a huge compliment from a guru in tools,
development and the developer community. Thanks Mike!

If you don’t know about the Daily
Grind
, read all about it here.

Jonathan Cogley isthe CEO and founder of
thycotic, a .NET consulting company and ISV in Washington DC. thycotic has
just released
Thycotic Secret Server which is a secure web-based solution to both “Where is my Hotmail
password?” and “Who has the password for our domain name?”. Secret Server
isthe leader in secret management and sharing within companies and
teams.

Feeling your users pain (and release notes for Secret Server 1.1)

March 27, 2006 2 comments

It is awonderful feeling to ship software -
it has been a long hard slog to get this round of features complete.
Especially while juggling our developers across various projects and client
work. This is also a welcome release as we get to use all the new features
in our own company Secret Server instance.

It is also a relief to finally get rid of those few
really annoying bugs that I deal with everyday. The process of dogfooding
your own application really makes you feel the users pain – there was a funny
(although silly) movie at PDC last year of Microsoft installing pain delivery
mechanisms for their developers – then every time a user got an error – the user
would feel the “pain”). Even though the movie was silly, it did get the
point across. Often it is difficult to feel that pain since the
application is in a business domain that just isn’t relevant to you (I remember
building a very specific and technical sewer management system for an English
county years ago and I didn’t even live in that county nor install
sewers!).

How do organizations deal with dogfooding when the
business domain is not relevant to the developers? A strict quality
assurance process that allows testers to inflict the “pain” on the
developers?

Enough rambling, here is the laundry list of all
the things taking up our time over the last few months …

(If you don’t have Secret Server yet, get it
here)

Release Notes for
1.1

* Support Microsoft Access as a file-based
database option

* Add import capability for CSV
files (wizard)
* Email notification of secret changes
*
Add support for Windows Authentication when using Microsoft SQL Server
*
Streamline the secret sharing process to reduce the number of
clicks
* Copy to Clipboard must be supported in FireFox (develop new
FireFox plugin
)
* Add Installation notes to installer
* Implement
masking password fields on secret add and secret edit based on user preference

* Generate password feature
* Change Installer to be more of a wizard
than a checklist
* Current user should not get notification of secret update

* Ensure that all Secret Server binaries are obfuscated for improved
application security
* Installer always reports access denied on write access
screen
* Installer: Allow the user to add a first user if there are no users
and no secrets in the system.
* Session timeout causes error during upgrade

* SmtpMessageTransport needs to be added.
* GetSecretViewUrl needs a
proper url location
* Add Email Address to user maintenance screens
*
Add a new column to the SecretAudit screen to show notes
* Add two new
options to Tools screen
* Mailto links should also send the SS version
*
Add current secret name to secret screens – sharing, history, etc
*
Configuration should be added to the toolbar
* Add password strength to
ChangePassword screen
* User Edit should not allow you to make edit that
would cause system to become dead
* Solve SecretView error on .NET Framework
2.0
* Usernames must be unique

Secret Server 1.1 is out … go and get it!

March 27, 2006 1 comment

I haven’t blogged in a few weeks but I have a few good reasons. Client projects with tight deadlines, the final push for our second big release of Thycotic Secret Server and also holding back on the irresistable urge to talk about features that aren’t released yet (not much of a marketing person, huh?). We have listened to feedback and added several features as requested by users. One of the biggest new features – new support for Microsoft Access -which means that you DO NOT have to use Microsoft SQL Server to use Thycotic Secret Server anymore! We also have a new built-in import tool that accepts CSV format so you can easily import your AnyPassword or Keepass secrets to try it out with no risk.

Watch this space for more snippets of new features, some details on the future roadmap and much more Secret Server yumminess.

POP QUIZ:

Where does your development team keep its passwords?

  • Password-protected Microsoft Excel file
  • Amagical piece of paper onsomeone’sdesk
  • Post it notes
  • On the whiteboard
  • What passwords?

What are you waiting for???? GO GET IT!
** http://thesecretserver.com ** Secret Server 1.1

Jonathan Cogley isthe CEO and founder of thycotic, a .NET consulting company and ISV in Washington DC. thycotic has just released Thycotic Secret Server which is a secure web-based solution to both “Where is my Hotmail password?” and “Who has the password for our domain name?”. Secret Server isthe leader in secret management and sharing within companies and teams.

Keep the numbers meaningful in Security Reviews

December 13, 2005 1 comment

I just came across this
post
(older) by Robert
Hurlbut
titled “DREAD is dead” and it reminded me of our experiences with
these same ratings today. We are in the middle of a Security Review for a
client and have been working through our threat model to assess the risk
associated with each item. DREAD is a technique for assessing such risk
using the factors:
Damage potential, Reproducibility,
Exploitability, Affected users and
Discoverability. As Robert mentions, the idea is to rate
the threat on each of these factors using a scale from 1 to 10. Then add
up all the numbers for each threat (average it if you wish) and youcan
list the threats in DREAD priority.

The obvious problem … what is the real difference
between a 7or a 8? That is a tough call especially when you have 50
or more threats to evaluate (consistency in your evaluation gets challenging
across that many items!). We decided to settle on a simple system of low
(1), medium (2)or high (3). We also simplified our analysis to just
include the traditional Criticality/Severity and Likelihood of Occurrence -
interestingly this is very similar to the Microsoft Solutions Framework (MSF)
approach to categorizing and managing risk on a software development
project.

Why all this effort to rate the risk? Most
projects (yes, even Security Reviews!) have limited budget.
Thismakes it important to use your resources on the most risky areas of
your system. This becomes even more necessary when you have to trade off
against items you will never have time to investigate.

Our risk analysis yielded a nicelist of
threats in the 4-6 point category which we can now investigate starting with the
most risky threats.

(Ps. The authors in Writing Secure
Code
, 2nd Edition, mention always giving a 10 for Discoverability as things
will always be discovered at some point … this again shows how DREAD is too
detailed and is not ameaningful measurement)

Jonathan Cogley isthe CEO and founder of
thycotic, a .NET consulting company and ISV in Washington DC. thycotic has
just released
Thycotic Secret Server which is a secure web-based solution to both “Where is my Hotmail
password?” and “Who has the password for our domain name?”. Secret Server
isthe leader in secret management and sharing within companies and
teams.

Follow

Get every new post delivered to your Inbox.