One-Time Passwords Do Not Provide Non-Repudiation

The title is obvious and it could’ve been a tweet rather than a blogpost. But let me expand. OTP, or one-time password, used to be mainstream with online banking. You get a dedicated device that generates a 6-digit code which you enter into your online banking in order to login or confirm a transaction. The device (token) is airgapped (with no internet connection), and has a preinstalled secret key that cannot be leaked. This key is symmetric and is used to (depending on the algorithm used) encrypt the current time, strip most of the ciphertext and turn the rest into 6 digits. The server owns the same secret key, does the same operation and compares the resulting 6 digits with the ones provided. If you want a more precise description of (T)OTP – check wikipedia. Non-repudiation is a property of, in this case, a cryptographic scheme, that means the author of a message cannot deny the authorship. In the banking scenario, this means you cannot dispute that it was indeed you who entered those 6 digits (because, allegedly, only you possess the secret key because only you possess the token). Hardware tokens are going out of fashion and are being replaced by mobile apps that are much easier to use and still represent a hardware device. There is one major difference, though – the phone is connected to the internet, which introduces additional security risks. But if we try to ignore them, then it’s fine to have the secret key on a smartphone, especially if it supports secure per-app storage, not accessible by 3rd party apps, or even hardware...

Solving Problems Properly Is Often Not Viable

How many times you, as a software expert, saw some software or process and thought “damn, this can be done so much better”. Yes, a lot. But why, since large organizations spend a lot of money on IT? Is it because software is too complex, is it because of organizational issues, is it legacy software, or just the way things are? And if what we see is so bad, isn’t common market sense saying that surely these companies will be disrupted and made obsolete by a new and better competitor? I won’t give a definitive answer why software is bad (I have already blamed developers, though I admit, developers are only a part of the problem). But I’ll try to reason about what it’s not getting replaced under market forces. Peter Thiel in his book “From Zero to One” says that a a new product has to be at least 10 times better in order to be disruptive. Everything below that is just gradual improvement over the status quo. Google was 10 times better than AltaVista, Lycos and Yahoo as a way to find information on the web. Skype was 10 times better than whatever was out there before that. But most of the things that we see as broken don’t get fixed because there’s no 10x improvement that would kill them. Let’s take a loot at a few examples. Banking. Banking is horrible. Online banking UX is usually on par with a legacy ERP, bank transfers rely on a patchwork of national specifics and ages old international standards like SWIFT. I can’t really think of anyone who really...

A Technical Guide to CCPA

CCPA, or the California Consumer Privacy Act, is the upcoming “small GDPR” that is applied for all companies that have users from California (i.e. it has extraterritorial application). It is not as massive as GDPR, but you may want to follow its general recommendations. A few years ago I wrote a technical GDPR guide. Now I’d like to do the same with CCPA. GDPR is much more prescriptive on the fact that you should protect users’ data, whereas CCPA seems to be mainly concerned with the rights of the users – to be informed, to opt out of having their data sold, and to be forgotten. That focus is mainly because other laws in California and the US have provisions about protecting confidentiality of data and data breaches; in that regard GDPR is a more holistic piece of legislation, whereas CCPA covers mostly the aspect of users’ rights (or “consumers”, which is the term used in CCPA). I’ll use “user” as it’s the term more often use in technical discussions. I’ll list below some important points from CCPA – this is not an exhaustive list of requirements to a software system, but aims to highlight some important bits. Right of access – you should be able to export (in a human-readable format, and preferable in machine-readable as well) all the data that you have collected about an individual. Their account details, their orders, their preferences, their posts and comments, etc. Deletion – you should delete any data you hold about the user. Exceptions apply, of course, including data used for prevention of fraud, other legal reasons, needed for debugging,...

Blockchain Overview – Types, Use-Cases, Security and Usability [slides]

This week I have a talk on a meetup about blockchain beyond the hype – its actual implementation issues and proper use-cases. The slides can be found here: The main takeaways are: Think of blockchain in specifics, not in high-level “magic” Tamper-evident data structures are cool, you should be familiar with them – merkle trees, hash chains, etc. They are useful for other things as well, e.g. certificate transparency Blockchain and its cryptography is perfect for protecting data integrity, which is part of the CIA triad of information security Blockchain (a private one) can be a good enterprise integration solution for multi-organization setups where trust is required Many proposed use-cases can be solved with centralized solutions + trusted timestamps instead Usability is a major issue when it comes to wider adoption As with anything in technology – use the right tool for the job, as no solution solves every problem. The post Blockchain Overview – Types, Use-Cases, Security and Usability [slides] appeared first on Bozho's tech...

The Personal Data Store Pattern

With the recent trend towards data protection and privacy, as well as the requirements of data protection regulations like GDPR and CCPA, some organizations are trying to reorganize their personal data so that it has a higher level of protection. One path that I’ve seen organizations take is to apply the (what I call) “Personal data store” pattern. That is, to extract all personal data from existing systems and store it in a single place, where it’s accessible via APIs (or in some cases directly through the database). The personal data store is well guarded, audited, has proper audit trail and anomaly detection, and offers privacy-preserving features. It makes sense to focus one’s data protection efforts predominantly in one place rather than scatter it across dozens of systems. Of course it’s far from trivial to migrate so much data from legacy systems to a new module and then upgrade them to still be able to request and use it when needed. That’s why in some cases the pattern is applied only to sensitive data – medical, biometric, credit cards, etc. For the sake of completeness, there’s something else called “personal data stores” and it means an architecture where the users themselves store their own data in order to be in control. While this is nice in theory, in practice very few users have the capacity to do so, and while I admire the Solid project, for example, I don’t think it is viable pattern for many organizations, as in many cases users don’t directly interact with the company, but the company still processes large amounts of their personal data....

Cybersecurity Is Very Important

A few months ago an essay titled “Cybersecurity is not very important” appeared. The essay is well written and interesting but I’d like to argue against its main point. And that is actually hard – the essay has many good points, and although it has a contrarian feel, it actually isn’t saying anything outrageous. But I still don’t agree with the conclusion. I suggest reading it (or skimming it) first before continuing here, although this article is generally self-sufficient. I agree with many things in the essay, most importantly that there is no 100% protection and it’s all about minimizing the risk. I also agree that cybersecurity is a complex set of measures that span not only the digital world, but he physical one as well. And I agree that even though after watching a few videos from DEF CON, BlackHat or CCC, one feels that everything is fundamentally broken and going to live in the mountains is the only sane strategy to survive an impending digital apocalypse, this is not the case – we have a somewhat okayish level of protection for the more important parts of the digital world. Certainly exploitable, but not trivially so. There are, though, a few main claims that I’d like to address: There has not been any catastrophic cybersecurity event – the author claims that the fact that there was no digital Pearl Harbor or 9/11 suggests that we’ve been investing just the right amount of effort in cybersecurity. I don’t think that’s a fair comparison. Catastrophic events like that cost human lives as an immediate result of a physical action. No...