Securing Plaintext Passwords

John Morehouse shows you how to fix plaintext password storage when you can’t fix the application:

Once the data has been encrypted, we can move forward with creating a new view that will be used to “head fake” the application. The view is named the same as the original table therefore the change is seamless to the application.  The application doesn’t know if it’s calling a table or a view so that’s why this works.

You should never store passwords in plaintext.  You should almost never store passwords in a reversable format (i.e., encrypted).  The primary case in which I can see storing passwords encrypted rather hashed is if you have automated systems (or non-automated technicians) which need passwords to authenticate somewhere.  Even then, there’s a lot of value in using OAuth tokens.  But if you can’t get around any of this, John’s solution does remove the really bad decision of leaving passwords in plaintext.

Related Posts

Talking To Secure Hadoop Clusters

Mubashir Kazia shows how to connect to a secured Hadoop cluster using Active Directory: The primary form of strong authentication used on a secure cluster is Kerberos. Kerberos supports credentials delegation where a server process to which a user has authenticated, can perform actions on behalf of the user. This involves the server process accessing […]

Read More

One CLR Solution

Solomon Rutzky continues his SQL Server 2017 CLR security series: This new requirement prevents the technique described towards the end of Part 1 from working. That technique uses a SAFE Assembly as an indirect means of creating the Asymmetric Key to create the Login from. That worked perfectly prior to SQL Server 2017, but now even SAFE Assemblies require that the […]

Read More


March 2016
« Feb Apr »