defence in depth.

Last week I read a post on Brian Krebs’ blog where security researcher Thomas Ptacek was interviewed about his thoughts on the current landscape of password hashing. I found Thomas’ insights into this topic quite pertinent and would like to reiterate his sentiments by talking a little about the importance of choosing the right password hashing scheme. The idea of storing passwords in a “secret” form (as opposed to plain-text) is no new notion. In 1976 the Unix operating system would store password hash representations using the crypt one-way cryptographic hashing function.  As one can imagine, the processing power back then was significantly less than that of current day standards. With crypt only being able to hash fewer than 4 passwords per second on 1976 hardware, the designers of the Unix operating system decided there was no need to protect the password file as any attack would, by enlarge, be computationally infeasible. Whilst this assertion was certainly true in 1976, a

A common recommendation I often come across is that Internet-facing systems should not be a part of an active Windows domain. As an exercise of interest, I have decided to look at this topic a little deeper and explore what advantage (if any) access to a domain member really provides. In this scenario I will demonstrate how to gain privilege within a Windows domain using only the tools available on a default Windows install. I will be working under the assumption that: I have access to a public terminal (or something similar) with up-to-date anti-virus. I do not have administrative access on the host. I do not have access to any third-party tools. Once connected to a Windows workstation, the first piece of information I want to find is the domain namespace. This can be done a couple of different ways: nbtstat –A <IP-Address> net config workstation Next, because I am working from a domain member, I can query the domain controller and check whether it’s aware of