Posts by Adam 1 2545 publicly visible posts • joined 7 May 2012
> transport of somewhat heavy batteries
Diesel weighs somewhere between 850g and 1Kg per litre. They tend to be in the 5L/100km range. The average car is driven 15-20 thousand km/year. Picking the kindest of those numbers, that means you are burning north of 6 ton of diesel fuel per year if you are a typical driver in a typical car.
That's in the ballpark of 3x the weight of these entire cars (not just the battery pack) every year
Refining petroleum takes somewhere between 1.5 and 2.5 KWhr/L by the way. A 60L tank therefore has a 90+ KW/hr electricity penalty just from the refining step.
And those 60L didn't just pump themselves from the well to the refinery nor do they pump themselves into tankers to your local service station running on air.
@chemist
Wasn't quoting your post so not quite sure why you would take my comment to be about you and your process.
I was quoting AC whose argument seemed to be that because people (not you obviously) choose crap passwords then running on a non default port gave the same security. I worked out the equivalent entropy it gave to point out that you really need a bad password for that to be equivalent.
I thought my post was pretty clear that this does not preclude taking additional steps such as non default ports or port knocking or timed activation for ports. That will improve your security or at worse make no difference and doesn't really make your life harder so go ahead with my blessing. It is a great additional step, not a replacement.
> but there's only so many ports that can be used.
65536 to be precise.
So as a password it is comparable to a 3 to 4 digit numerical PIN; or comparable to a password made up of a single English word that is in common use. It just isn't enough as a substitute method.
It may be what you meant but it isn't what was written and what I responded to
> Or a simpler (than SSH) solution
This implies that the proposed solution is a replacement.
I simply suggested that for me to accept such advice, I would have to then accept security through obscurity on equal argument.
Note that I am not arguing that obscurity doesn't have a part to play. When I was younger and actually went bush walking, we would often park the 4wd off the fire trail behind some shrubs or an embankment where it wouldn't be easily visible from the said fire trail. It didn't substitute for locking your doors, but it did reduce risk from the opportunist smash and grab. By all means, run on non-default ports or use port knocking; but call it a suplementary measure not a solution in its own right.
> The basic premise is any secure system with enough time and effort will be broken
Realistically that is correct, but only because developers are humans with SNAFUs like in every other endeavour. Usually it is flawed implementations which are attacked.
For example, it is possible to choose a key size such that even allowing for Moore's law to continue and the entire GDP of the world dedicated to breaking it would still take longer than our sun has left in it. But all that is based on our assumptions about the trapdoor functions that we rely upon. We assume that factorising the multiplication of two huge primes is really hard. We assume that the discrete log problem is really hard. But find some new mathematical construct then maybe it can be done with less effort. In fact if you look at the logjam attack it takes advantage of being able to precompute millions of CPU hours worth of computations and reuse that to simplify the computations for subsequent keys.
But I digress. My point is that the goal is impossibility without the key. Good enough means uneconomical to crack (I think your point) but with the proviso that hardware reduced the cost per operation over time (in both time and power consumption), and sometimes your enemy is a miscreant who is paying for neither (malware / stolen Amazon keys / etc). If you accept the good enough argument, you need to make sure you adequately measure the economics rather than just trying to figure out what it would cost you to do.
Don't get me wrong, bricking a device is bad but it could be worse.
> A hash function, in a cryptographic sense, takes a chunk of data and makes it into another anonymous-looking chunk of data that is, to all intents and purposes, impossible to revert back into the original form
Using the phrase that is to all intents and purposes impossible to revert hits pretty close to the complaint.
It implies that maybe some TLA has enough resources to do it but no bad guys can. It is the wrong way to think about hashing. It is absolutely impossible to determine the source value. The process is deliberately lossy so it isn't just a matter of CPU power. It isn't just a trapdoor function like prime factorisation (hard) vs multiplication (easy) or the discrete logarithm problem.
Literally the only way to find the source is to try and brute force or dictionary attack the hash. But in any case, a reversal isn't normally the goal. An attacker is usually only after a reversal or collision because either way you can authenticate with it.
For some perspective, the cost of generating a collision for md5 is less than a dollar. Generating an sha-1 collision is in the order of 75,000 dollars.
For most threat models, collisions on sha-1 are not a real world issue just yet; but it takes a while for it to work its way through the system. If you keep using sha-1 certificates, then by the time those new certificates expire then the collisions will probably be heading towards half that price. The point was to sunset it before it got to the point of actually being insecure.
> 1990s: a user prompt from global logistics system developed internally and rolled out to 30-plus countries.
Are you sure you want to cancel the shipment?
Yes / No / Cancel
So kinda like the HP Print Service plugin for android that in 2016 asks whether you are sure you want to cancel your print job.
OK / Cancel
Firstly, there is nothing special about a hoverboard in the way it utilises batteries. It is not any more or less explosive than a laptop or an electric bike.
Unlike lead acid (the more common predecessor for electric bikes and scooters), you can't just pump in energy at full pace until it's full as the reducing efficiencies allow runaway waste heat to build up. So it is quite conceivable that cheap no brand companies based, er, in countries that lack strong safety regulation frameworks* would take dangerous shortcuts.
Blaming the product category is counter productive**. We need to call it for what it is. Products from specific vendors do not meet our electrical safety standards. Those products must not be sold and already sold units must be urgently and actively recalled.
Now I'm not drawing the same conclusion as the subby here, at least not from the article itself. All I am seeing is (from an IANAL perspective) is that the manufacturers who don't meet these safety regulations can't sell their wares here and people who otherwise acquire the said wares can't use them here. Makes sense. Li fires aren't much fun.
*which suddenly become very good once it causes embarrassment for the establishment.
**the legitimate vendors get caught up in the ban but the fly by night ones that are causing the problem are trading with a different name later the same week.
API monoculture isn't what is described though, at least not in the openSSL sense.
Heartbleed was two flaws; a stupidly designed API call and a buggy implementation of it. The stupid design was to allow the caller to independently mention the size of the buffer and the amount of data to read when it should have derived one of those pieces from the other. But the stupid design only matters because of the implementation bug whereby the server failed to validate that an untrustworthy client could manipulate those numbers to read additional information from memory.
Unless I misread the article, all that is proposed is a common API that each bank would independently evaluate the best way of implementing. So if the design was flawed, some banks would be caught pants down and others would return an error.
It's more similar to ART vs Dalvik vs Oracle implementations of the same method calls (but no points for guessing which of those would have the crap security implementation)
> Secure. Efficient. Cheap
> Pick two.
In this case, that doesn't apply. You cannot pick both secure and efficient even if you don't care about cheap.
The point is that simply knowing that two parties are communicating at a given time does leak some information. You can only counteract this by (at least occasionally) communicating with the other party either nonsensical data (eg randomised bits) or misleading data (eg legitimate looking real message that both sides of the communication know is to be ignored). Either way, that is less efficient than if you only sent bits when you wanted to say something.
> It wouldn't protect against a dealership unwittingly distributing hacker created firmware.
You're right if the dealer intended to flash the firmware, but if they were only intending on reading the reports from the computer to work out why whatever warning light was flashing then there would be no need to write anything.
> I assume it would 'auto toggle' under a certain set of conditions
Not auto toggle. Auto toggle off. There is an important difference. There should be no way to activate writeable mode without physically moving a switch.
There are heaps of ways to auto switch off, from a simple timer to hooking it up to the ignition key removal to locking the doors to immediately doing it when whatever JSON or whatever writes the binary image then restarts the computer.
> Actually breaking a password made up of a sentence containing several words is straightforward - random letters, numbers and non-alpha characters are much harder. Can't remember where I read that though...
It's probably good you can't remember where you read that because it is bad advice. Your password strength is log base2 of alphabet size to the power of the length of the password. Bigger is better.
For example, consider a 4 digit PIN for an ATM card. The alphabet size is 10 (0 through 9) and length is 4, so the strength is log2 of 10^4 = ~13 bits of entropy
If you jump to say a 10 character random password, we have to agree on the alphabet first. Say 26 lower case + 26 uppercase + 10 digits + 30 symbols (the ones I can easily type with my keyboard here) + 1 space = 93. log2 of 93^10 gives ~65 bits of entropy.
Now consider a password made up of 4 randomly selected words**. In this case, it is disingenious to consider the alphabet to be the same size as the random password (although in practice it would require the attacker to know that you didn't use such symbols). Let's assume they know your technique for the minute, and let's assume English only for simplicity, and lets assume you capitalise the first letter of each word. In this case your alphabet is about 350,000 and your length is the number of words you use. log2 of 350000^4 gives ~74 bits of entropy.
So RinseBubbleOvalBounce is ~500 times harder to crack than GV45#5kd3;
Both passwords offer excellent protection, but I know which one you would have to write down.
**Of course if the words are not chosen at random (eg a verse or quote or meme or something) then it will be no more secure.
Produced a flat CSV file to push some data into a third party system. User has Excel and proceeds to double click the file. Excel helpfully and silently truncates any leading zeros. User closes and is prompted to save changes, of course answering yes. Now file won't import (best case) or imports wrong data (which is really hard to recover from in this case). Total PITA.
Biometrics are by definition observable and something you are so can't fulfill the concept of something you know like a password. In some ways that makes them worse choices because you can't just change them if they get stolen and they can get lost if you have to bandage up your digit due to an injury. Some materials actively erode the ridges (things like pineapple or beer believe it or not) so people working in certain industries can have trouble getting something unique anyway.
But if you consider them like a 2FA rather than an authentication in their own right, it is better than what it replaces. PINs can be viewed by people standing behind you. Whilst lifting a fingerprint off a surface is reasonably trivial, you also need the device. A fingerprint door latch for example could be argued as insecure, but is it less secure than the pin and tumbler it replaced?
Maybe, maybe not. YMMV depending on how much companies have manage to get in the pocket of legislators.
Here in Australia, the consumer law allows you to get a repair or refund (vendors choice btw) for a major fault.
A product or good has a major problem when:
it has a problem that would have stopped someone from buying it if they’d known about it
it is unsafe
it is significantly different from the sample or description
it doesn’t do what the business said it would, or what you asked for and can’t easily be fixed.
That is arguably 4 from 4 on the definition of major fault.
You are right to say that the upgrade is optional, but if they don't provide security patches on the older major version, that itself would be a major fault.
If they fork android, two important things would happen.
1. Trademarks mean they can't call it android or have a cute green robot icon.
2. They can't hook it up to the play store. Whilst Samsung have their own cess store, it is hardly an inspiring place.
In the words of a knighted man, thanks a very brave move.
It occurred to me that the number of wrong attempts must be written somewhere non volitile.
It can't be encrypted with the actual key (although could be encrypted using the hardware ID). How do the iphones protect themselves against overwriting that block of storage between each guess so as far as the phone knows it is the first guess?
Cracked is too strong a verb. It has a particular weakness where a lot of the effort that is needed to compute it can be shared across groups of keys. If you have TLA level resources you can precompute the common keys then attack the final stage in a practical timeframe. Use 2048 bit or higher or ECDH and you are safe (as far as we know of course), but it is reasonable to assume that the TLAs can get to things below 1024 bit.
More:
https://en.m.wikipedia.org/wiki/Logjam_(computer_security)
> The new HTML based home pages that we have released are indeed served via HTTP, however the API called to authenticate a user is most certainly HTTPS
I hope that I am misreading that sentence.
It is important to authenticate via HTTPS, but equally important to deliver the JavaScript that talks to the API over HTTPS as well. Otherwise a miscreant mitm will just alter the JavaScript on the way through. Same vulnerability when embedding a HTTPS iframe in a page delivered over HTTP.
Another (recently fixed) real world example of the same attempted argument:
http://www.troyhunt.com/2016/01/thank-you-waitrose-now-fix-your.html
To be honest I am having trouble identifying any.
Good? It leaves the worst conditioned bits of the copper in the ground and adds new nodes that need active power and cooling, look unsightly and will need future upgrades as technology evolves and will be obsolete by the time it is rolled out.
Cheap? Yeah 'bout that...
Fast? Well it is 2016 and the numbers speak for themselves.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
