Cryptography education

After a long break, I finally got back to writing yet another post (coincidentally, about what I did the last few months).
As cryptography is quite essential part of security engineering I decided to challenge myself by doing online course by Dan Boneh from Stanford called Cryptography I.
Originally I didn't expect that university courses go into much detail of how crypto algorithms are implemented in practice, but this course surely changed my opinion on practicality of university lectures. Of course I should have known that lectures from famous universities like Stanford are  expected to be worth the tuition fees.

Course content

Despite the practical nature of this course, it requires very good understanding of various areas of Math as well as the scientific method of lectures.
This actually was important part of practicality, as some areas of security engineering require or expect a mathematical proof of algorithm or process security. I'm not sure how such proof  would hold in front of an average auditor, but this course surely does good work proving weaknesses of explained cryptography functions.
The first course contains brief introduction with a short refresher in discrete math and goes right into stream and block ciphers (like DES or AES). Later it covers message integrity and hash functions and finishes the course with public key encryption (RSA and ElGamal).
The second course (expected to take place in June 2015) would surely bring more advanced and recent topics like elliptic curve cryptography or maybe digital currency concepts, so there's more to learn.
In most of the topic practical examples were given on how some services or protocols used the cryptography in wrong way.

Programming part

Besides the theoretical part it also included coding assignment, where the tasks were from encrypting content in efficient and secure way to deriving keys from insecure implementations. This experience would surely be very useful in code review or penetration testing work.
All the programming assignments were done in Python, with help of various libraries that offered the necessary crypto algorithms already implemented.

Conclusion

Everybody in the field of security who wants to call himself a security engineer should do this course (and pass), as the knowledge gained is very important in many areas of the security field. Whether one does security policy (to define acceptable crypto algorithms/key sizes etc.); ensures application security (performing code reviews or testing); provides authentication, file or storage encryption or builds VPNs, this course will help to understand what are the implications of choosing one or the other security algorithm and what would be the performance and security impact of these decisions.
With recent openssl vulnerabilities I can't stress enough how this knowledge improves the decision-making whether or how to deal with these vulnerabilities.

Offline Password Management System

Intro

In many companies the authentication management is quite easy to do. That is if they only have one IT team and simple network infrastructure. Just putting in one LDAP or AD server should do the trick, one would believe.
But the world is not always that easy. There are more complex and heterogenous environments, with multi-department/team organizations and environment segmentation, where having something like central authentication server is just not feasible.
Also for some applications or systems it might not be possible to use something like remote authentication service.
In these cases, local authentication is the only option. Which makes account/password management a bit complicated.
So let's think about such scenario, where there are lots of accounts/logins/passwords and some of them are shared others are personal and describe how such offline system could work.

Accounts and Systems

The most important task to do is to create a list of roles and systems, where these accounts (should) reside.
These systems can be anything from specific applications down to pin code for room access. As the goal is to keep track of any accounts, therefore even physical elements should be considered.
When it comes to types of accounts, there usually are two types:

Personal accounts

Personalized accounts are important part of change tracking function, auditing function and other security controls, so I expect many systems would have such accounts and tracking and maintaining such accounts can and should be done by the person owning them.

Shared accounts

Shared authentication is used in areas where only one account can have all the rights (root account) or service provider supplies only one account (support or administration account) or the account is connected with a role that is performed by whole team (monitoring or support account).
Another type of shared account is system accounts, where one application needs to authenticate to other (e.g. client(s)->server relationship).

Changing such accounts can be difficult, as the information has to be shared with all the people that are part of the owner group. It's not a good practice to send the password unencrypted to everybody in the group, and encrypting it with one shared phrase makes it difficult to send it to new group members or those who forgot the shared encryption phrase.

Password management concept

So in order to track these accounts, the solution should be able to identify and distribute the account data only to the users that need it.

To do that, there should be 3 lists (or tables) of information:

• list of all the accounts (on network elements, OS, applications, databases, etc.) 
• list of all the account owners (potential account holders, can also be systems or applications that need an account)
• list of all groups with people as members (teams, people with the same role or responsibility, etc.)

List of all accounts with systems, where they reside, is useful for identification of all the places, where changes have to be performed if one account has to change. There shall be no password stored in this list (

List of all account owners, should contain their public keys and delivery method for encrypted passwords (protocol/email/storage/ whatever the user likes).

List of all groups links account owners with accounts, so for personal accounts it would be one2one link and for shared accounts it would be one to many. For any future functionality there also can be group of groups or one2half (2 people holding part of the password each).

So application should have or use these lists to manage the account operations that are usually done in a standard IT environment.

Day-to-Day Operations 

Let's see how day-to-day operations with such a solution would look like:

New account creation

1. identify all the systems that need to have this account
2. generate a password 
3. set the password on the system(s)
4. distribute the password to all the group members

Shared account membership change

Here the question is whether to choose optimal approach (and for new addition just use the same password, but encrypt it for the new owner), or secure approach (generate new password every time there is a change in the group list). With minimum overhead I think it's better to do the later (being a security engineer afterall):

1. add or remove person in the group list
2. generate new password for the account
3. set the password on the system(s)
4. distribute the password to all the group members

Password change

This task should be the same as the new account creation.

1. identify all the systems that have this account
2. generate new password for the account
3. set the password on the system(s) identified
4. distribute the password to all the group members

Account expiry/deletion

1. identify all the systems where this account is used or shall be deleted from.
2. remove it from the list
3. delete or disable the account on all these systems

Available solutions

Although I didn't spend much time testing various multi-user password management applications, I found following worth investigating:

• Pleasant Password Server (supports KeePass apps)
• Secret Server
• KeePass or PasswordSafe (using designated storage like network share or rsync for synchronization)

Of course, a solution that requires constant connectivity to a password server defeats the purpose intended, so the connectivity is only required to synchronize password database for the user.