500 UKP computer.
2450 UKP extra costs incurred by dealing with the UK government's self-serving bureaucracy.
50 UKP delivery.
It's GBP - for Pound Sterling. Admittedly not as intuitive as one would first think (Great Britain Pounds? No).
In embedded devices like these, there is no reason to use a root password. The devices should be locked down completely with a process to update them with signed firmware.
If they need some form of remote access, they should at the very least use SSH PKI.
I think he's actually unemployed and out of money and needs to save his $$$
The summary suggests otherwise: "I'll also still have access to the internet at my office"
First off, QANTAS had a fatal crash in 1951.
You are of course correct, they have had fatal crashes in the past. But none with jet engines. I.e. nothing in the modern era. I'd prefer we had a rolling scale approach that reflects the average working life of modern planes, e.g. in the last 20 years has the airline had a fatal crash?
Easy to stop
- Don't allow zip files with passwords (or any other compression format)
- Inspect individual files in compressed archives for checksum matches (i.e. lolcat.jpg not matched, but game.exe is, so is README.txt, etc...) and if enough of the individual files match known checksums, flag it for human inspection.
- Check all files to identify what filetype they are - jpg/zip/gz/tar/etc... if the file type is not known, disallow it. Yes I'm sure someone will invent a zip file format with a JPG header.
- Perhaps for 'identity verified' customers (users who you have confirmed their phone/address somehow, e.g. TXT postal letter activation code) you lift the restrictions on no encrypted files, and also allow files of unknown type.
- Video and Audio are harder to detect than other lossless filetypes, as the user can modify it easily to change its checksum without destroying the content. There are some algorithms that fingerprints aren't affected by such changes but they're typically a lot more specific to the given filetype and I imagine quite intensive to run compared to a typical SHA/MD5 checksum.
For 'online' systems which lock accounts after a small number of tries, it would *seem* like an 8 digit alphanum password (which isn't one of the trivial ones discussed earlier) would be sufficient, wouldn't it?
More than likely it would be fine. I guess I was commenting more on your question of brute force attacks being relevant in the days where you get X tries then the account is locked. If you choose even a moderately sane password (i.e. no sequential numbers, no keyboard sequences, no common words) then you'll be a lot safer than most people.
But attackers these days are more interested in *any* account, not a specific account. So brute force hacking has shifted from brute force passwords to brute force usernames. Imagine trying tonnes of common usernames (email@example.com) against the top 3 most common passwords. You're bound to strike gold soon enough. Attackers will most likely have access to large email databases of legitimate addresses to use in their attempts. Sites allowing / encouraging / requiring you to use your email as your username these days only make such attackers easier.
Memory fault -- brain fried