> This update provides more information about the cybersecurity incident that we first announced on October 28, 2023, the day it first came to our attention. It has been a very challenging time, and we are deeply sorry for the concern it has caused. It is so unfortunate that data security and ransomware incidents are becoming increasingly common, and that public sector organizations including hospitals, schools and libraries – all dedicated to the betterment of the community – are being targeted.
I work from the British Library a few days a week, it's been quite chaotic (especially the first few days). The entire digital catalog is unavailable, let alone reserving books from the archives.
Public Libraries on the internet need to be static websites where anyone can read a book in the browser. Which means you need one more static website that knows which book is hosted at which library.
Obviously all of these sites need to run without JavaScript and the funding has to come from Companies interested in hiring educated folks who have read a few books. Every book needs to be in the language it was written in and in the public domain but that goes without saying.
People will figure out how to find and read a book from one of these online libraries if they want to.
This is a very uninformed take, the real world is not this easy.
Let’s just for a second assume they built a static only website (setting aside all your requirements to provide some way to read a book online which is ridiculously complex due to legal requirements to protect the content, data formats, and even simple things like pagination), most people in this thread thread would be commenting about how stupid it was that in this day and age one of the largest and most important libraries in the world only has a static site.
The fact of the matter is that everyone has expectations, providing this service is not rocket science but security is hard and you need constant vigilance to stay up to date and safe. This is why all you kids who are like oh yeah I can just build x don’t realize that for the majority of ‘x’ the build part is the easy and cheap part, the maintain is the hard and expensive part.
This is a nice intention and would be great for security. It works fine for displaying opening hours and upcoming events, etc. However, as soon as you want to search for books, or you want some log in feature to see which books you have loaned out and when they need to be returned, it's clear that a purely static site just doesn't cut it for today's expectations.
Sorry the dumb question, but why not?
Can't I make a static page that offers search (reload on every query with results) or profile (reload every time soemthing is changed in the profile)
I think your understanding of "static" website is off.
A static site does not have any backend, thus cannot provide you with search results because it cannot do any computing at all (just provide you the same (static) content again and again).
Actually some subset of this functionality is possible with static or semi-static pages but actually the problem is not so much about a page being static or dynamic but about being read-only vs getting user input. As soon as you need to deal with user input, there are inherent security issues.
You can go around these by having some presets in the profile and providing cached results for the most common search types but this is more or less as far as you can go.
Strictly speaking, you are correct. But in this case dealing with user input such as headers and their modifications is the responsibility of the server just like dealing with potentially malformed HTTP replies is the responsibility of the browser. What we are talking here though is the possibility of interaction with the remaining elements of the system (application, database). If these are read-only, the attacker loses these attack vectors.
Any reason it can't just have a JSON page somewhere, and then the search simply be a JavaScript app that looks through that static JSON for all the entries that contain a given token in it's list of keywords?
My money is on there being some poor middle manager who’s spent the last few weeks crying and pointing at the years of “we’re dangerously understaffed” memos they’ve been fruitlessly sending to their bosses.
That’s too vague to say that. It could also mean “we aren’t sure exactly when the attacker could have intercepted traffic” or “not everything uses the strongest possible hashing algorithm”. At a time like this, do you want people who are incredibly busy trying to guess whether the attacker has the resources to effectively attack every combination of hash algorithm, salt, etc. used anywhere at a large organization?
If you’re suffering a catastrophic breach - I’ve heard at least a VMware host-level compromise – it’s likely that it’ll be hard to tell exactly how much or how long an attacker had access to, so giving conservative advice is better than having to later issue an update saying people who thought they were safe weren’t and your earlier advice means that the attacker had more time to try to compromise them. Changing passwords is much, much, much cheaper than recovering from a breach.
If you are not using oauth, you are storing a hash of the password somewhere, right? Even with all the precautions, it is likely that if your password is a dictionary word, it can be broken. Given most people might be choosing a simple password and people tend to reuse the same password across sites, it is worthwhile asking people to change it.
Salting slows down dictionary attacks. It doesn't make them impossible.
If the site is able to verify a password with reasonable effort, an attacker that stole all relevant data is able to check a password with that level of effort.
Without a salt, an attacker has to spend the effort once to check against all users' passwords. A salt doesn't meaningfully increase the cost to check against a specific user but slows down attackers (who want to check a password against all users), so yes, you should have it. Additionally, you should use "expensive" hash functions. If you use 28999 iterations of PBKDF2 with SHA256 (an example config that I found in a benchmark, far from the state of the art but likely still very common), that means trying the 1000 best guesses against your million users is 10000 * 1000000 * 28999 hash calculations. Unfortunately, a RTX 3090 can do 129400 sets of 28999 iterations per second, so trying the entire dictionary against all users will take less than a day (https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...).
Even with a better algorithm, if you expect to be able to log in 100 users per second on your server (spending all resources on password hashing), the attacker will be able to test at least 100 passwords in the same time using the same resources (realistically more, because the attacker will likely have a better optimized setup, since their machine does nothing else but try passwords while yours is optimized for something else).
Let us say you do unix style passwords - generate random salt and store the salt with the password. Hashcat can run through 54 billion md5 hashes/17 billion sha-1/7 billion sha-256 hashes on a single pc per second.
Asking people to change the password as a precaution does not sound bad at all.
> This update provides more information about the cybersecurity incident that we first announced on October 28, 2023, the day it first came to our attention. It has been a very challenging time, and we are deeply sorry for the concern it has caused. It is so unfortunate that data security and ransomware incidents are becoming increasingly common, and that public sector organizations including hospitals, schools and libraries – all dedicated to the betterment of the community – are being targeted.
* https://www.tpl.ca/