I blinked when I saw the warning, “Your password can’t be longer than 16 characters.” I couldn’t believe that I had gotten that warning, so I erased what I had typed for a password and started typing 1, 2, 3, etc., to see if this warning did trip at 17 characters. It did. Why in the world is there a limitation on password length if you’re going to do a hash my password? And if you had to pick a limit, why 16 characters? Why not 50 or 100 or 255?
I’ll go one step further: there is never a good limit to how long a password should be. For services like these, Microsoft should have the plaintext version of the password (which again, should be a string of an arbitrary length) only enough to perform an adequate number of rounds of hashing and salting using an appropriate hashing function (e.g., bcrypt). At that point, once the password gets hashed, the hash is always the same length, meaning the length of the plaintext is irrelevant for storage.
Dynamic data masking is a great product and solves some niche problems that come if you need to do certain testing with live data at the application level. You should, however, beware of using it as a database-level security device.
I haven’t yet used it in testing because I don’t have the problem that it solves.
The problem that it solves is for people doing testing, especially user-acceptance testing, of an application using live data. It is good at masking data where the user is unable to make direct access to the database to execute queries.
Phil has code to get around credit card numbers, and I will say that he’s not the first person I’ve seen do this. Dynamic Data Masking is not a general-purpose security solution.
HIBPwned is a feature complete R package that allows you to use every (currently) available endpoint of the API. It’s vectorised so no need to loop through email addresses, and it requires no fiddling with authentication or keys.
You can use HIBPwned to do things like:
Set up your own notification system for account breaches of myriad email addresses & user names that you have
Check for compromised company email accounts from within your company Active Directory
Analyse past data breaches and produce charts like Dave McCandless’ Breach chart
The regular service is extremely useful and Steph’s wrapper looks like it’s worth checking out.
Dimensionality reduction is a common techique to visualize observations in a dataset, by combining all features into two, that can then be used to draw the observation in an scatter plot.
One popular algorithm that implements this technique is PCA (Principal Components Analysis), which is available in R through the prcomp() function.
The algorithm was applied to observations of sthe dataset, and ggplot2’s geom_point() function was used to draw the results in a 2D chart.
I would want to see this done for a couple hundred thousand domains, but I do like the idea of taking advantage of statistical modeling tools to find security threats.
I’m at a conference, specifically a security conference. So I looked at the available WiFi connections. Among the conference and hotel specific connections and the MiFi and cellphone uplinks I spotted this one
My little Wifi hotspot has an SSID of Flowers By Irene.
Now, we’re getting somewhere. Looking at this graph we see we have four high-level problems we are trying to solve.
(Unknown/Unknown) The first step in realizing that we have a problem is accepting that we may not have the answer. We may not have the right mental or computational models; or even the right data to find bad things.
(Known/Unknown) We’ve invested time and energy brainstorming what could happen, sought out and collected the data we believe will help, and created mental and conceptual models that SHOULD detect/visualize these bad things. Now, we need to hunt and seek to see if we’re right.
(Unknown/Known) We’ve been hunting and seeking for some time tuning and training our analytical models until they can automatically detect this new bad thing. Now we need to spend some time formalizing our response process to this new use case.
(Known/Known) Great, we’ve matured this use case to a point that we can trust our ability to detect; maybe even to the point of efficient rules/signatures. We have mature response playbooks written for our SOC analysts to follow. Now we can feel comfortable enough to design and implement an automated response for this use case.
I think his breakdown is correct, and also would reiterate that within any organization, all four zones come into play, meaning you have different teams of people working concurrently; you’ll never automate away all the problems.
1. Work backwards
Jot down when you were first notified of the breach and start to retrace the events that led to you being notified. This may mean investigating logs on databases, firewalls, routers and everything else in between. It’s a massive job to sift through all of the log data trying to find that one event that led you to receive that dreaded call. Fortunately, the data analytics field has been used in recent years to speed up the investigative work by pulling together multiple log files and analyzing it for anomalies.
As a technical guy, the “hire a PR firm” part did not come to mind.
Before I go on to the main body of this text, I would like to make a short digression about security in general.
Security is often in conflict with other interests in the programming trade. You have users screaming for a solution, and they want it now. At this point, they don’t really care about security, they just want to get their business done. But if you give them a solution that has a hole, and that hole is later exploited, you are the one that will be hung. So as a programmer you always need to have security in mind, and make sure that you play your part right
One common mistake in security is to think “we have this firewall/encryption/whatever, so we are safe”. I like to think of security of something that consists of a number of defence lines. Anyone who has worked with computer systems knows that there are a lot of changes in them, both in their configuration and in the program code. Your initial design may be sound and safe, but as the system evolves, there might suddenly be a security hole and a serious vulnerability in your system.
By having multiple lines of defence you can reduce the risk for this to happen. If a hole is opened, you can reduce the impact of what is possible to do through that hole. An integral part of this strategy is to never grant more permissions than is absolutely necessary. Exactly what this means in this context is something I shall return to.
This is a must-read for anyone interested in rights management in SQL Server.
For those not familiar with the SQL Server Connector, it enables SQL Server to use Azure Key Vault as an Extensible Key Management (EKM) Provider for its SQL encryption keys. This means that you can use your own encryption keys and protect them in Azure Key Vault, a cloud-based external key management system which offers central key management, leverages hardware security modules (HSMs), and allows separation of management of keys and data, for additional security. This is available for the SQL encryption keys used in Transparent Data Encryption (TDE), Column Level Encryption (CLE), and Backup encryption.
When using these SQL encryption technologies, your data is encrypted with a symmetric key (called the database encryption key) stored in the database. Traditionally (without Azure Key Vault), a certificate that SQL Server manages would protect this data encryption key (DEK). With Azure Key Vault integration for SQL Server through the SQL Server Connector, you can protect the DEK with an asymmetric key that is stored in Azure Key Vault. This way, you can assume control over the key management, and have it be in a separate key management service outside of SQL Server.
Check it out, as it might be a solution to some key management issues.
The core RC4 algorithm is well-known, and relatively simple. It would be better implemented in a .Net language for efficiency and performance reasons, but there is a T-SQL implementation below.
These two T-SQL functions implement the RC4 key-scheduling algorithm and pseudorandom number generator, and were originally written by SQL Server MVP Peter Larsson. I have a made some minor modifications to improve performance a little, and allow LOB-length binaries to be encoded and decoded. This part of the process could be replaced by any standard RC4 implementation.
Using WITH ENCRYPTION is a gentleman’s agreement that you won’t look at the underlying code. In practice, it’s trivial to get around, and Paul shows exactly why.