if only
... SO provided some mechanism to register the fact that you disagreed with a solution such that the better solution bubbled its way to the top, and a comment box where you could provide a reason for why you disagree.
2545 publicly visible posts • joined 7 May 2012
I don't think that it is going to operate in the way imagined by some commentards. Whilst I would leave open the possibility of personal ownership, my money would be on these share vehicles being operated by a fleet company.
To the concern about not having a car in an emergency or having to wait 10 minutes, or being too rural, I don't think they are deal-breakers. How many families do you know with two cars, where for the most part one of them is almost only used to transport someone to and from work and maybe the odd errand? It can easily be 10K a year to operate a car once you include depreciation, insurances, registration fees, servicing, tyres and fuel. That is not to even talk of having to have additional garage/driveway/kerb space to store such vehicles for the most of the time when they are at home or at the shop or whatever. Public transport may not be an option between the places and at the times needed, or may add half an hour to each trip, or may feel unsafe waiting at a poorly lit bus stop awaiting a bus that may not arrive, so whilst we might argue that public transport is a better option, the reality is that public transport operators cherry pick the routes with the highest patronage.
If families kept their primary vehicle, then a compelling case could be made to ditch that second car and use some on demand system not unlike Uber. This could be a fraction of the cost of ownership. You don't have the inconvenience of getting the thing serviced or repaired or new tyres or checked for rego or having to decide when it's time to sell it. If you are going from suburb to city for business, you probably end up sharing a van with 3-6 others with your fee heavily discounted. Getting a new fridge? Take a ute with you to the shop. Actually, take whatever comes with you and order a ute home. Flying somewhere? No need to rent a car at your destination. No need to even pay the extortionate airport parking rates to leave a perfectly functioning vehicle a few 10s of Kms from home for a week.
It's not going to happen overnight. It doesn't have to. But my prediction is that most kids born in 30 years time will have a puzzled look when you tell them about how you used to spend a double digit percentage of your income on owning a car that you left in your garage except for a dozen trips per week.
@yogan
"However, we're told, there’s also CryptSIPVerifyIndirectData, which can be abused to green-light malicious applications with a counterfeit signature. The only thing you need are some coding tools and, oh yeah, admin privileges on the target computer."
If you are not mistaken then Iain is.
What about hiding it in gcc / msbuild.exe so it injects the payload (ie the Ken Thompson Hack)
It'll never happen due to vested interests, but the simplest solution would be too tax at the higher rate between seller and buyer. In the French/Irish example, the tax to the French sale is 33%-15%=18%.
There may still be benefits to setting up these shell companies but they would need to derive from efficiencies or value add rather than tax avoidance.
I guess the other way would be to apportion 50:50 between seller and buyers jurisdictions. So back to France and Ireland, Ireland gets 7.5% and France gets 16.5%.
Aside from getting everyone to agree on the treaty, what would stop such a scheme from being a practical solution to the wealth transfer open only to global megacorps with sufficient tax lawyers?
Usually you to both. A secret string known to the server but not in the database, and a secret they is unique to each account. Your goal is to increase the cost of each guess that the bad guys need to make whilst not making your validation unfeasibly slow. They are used for protection against different attack vectors. Both will protect against a rainbow table (just a reverse dictionary measuring in GB or TB of millions or billions of hashes and the corresponding password). The power of a rainbow table is in reusability across multiple attacks and pretty much any reasonable length salt will mean that the hash won't be known up front (ie the bad guys need to invest a lot more, which is good)
A per server salt (rather per environment/application/etc) is useful because your validation logic knows that secret but it isn't in the database. That means that when the mongodb is left open to the world (don't get me started) it is still not possible to find the relation between password and hash.
A per user salt will inevitably require something accessible in the database (either encoded into the hash itself or in a field pertaining to the same field that doesn't change like username). The prime benefit of a per user hash is that if you and I use the same password because we like the same footy team or the same book (and we like most people don't follow recommended practice with password generation) then figuring out my password doesn't give away yours as it would if the hashes matched. Worse still, if my password hint gives away my password and my hash matched yours, that further weakens things. Worse again, I can find common hashes and collate all the password hints and join the dots. A per user hash solves all those.
Either way, don't roll your own scheme. Find a framework and use it. Recommended either bcrypt, scrypt or argon2 which use schemes that are much better at protecting against this and other attack vectors and generally require very little effort to implement.
> Does using dictionary words not simplify the brute force attack?
Reimagine every word as a character in your alphabet, and then the number of words used as the length. Using English and a 50,000 word dictionary and taking 5 words at random*, the number of permutations is 50,000^5 or 54 bits of entropy or roughly the same as an 9 character completely randomly selected password of mixed case and digits.
So it's well beyond brute forcible.
* That is absolutely essential for this scheme. Don't choose them manually because your brain is too predictable.
SoundingSqualidMopeAntler is both easier to remember (you probably already have) and several orders of magnitude harder to brute force than your suggestion.
As long as you choose the words randomly from a dictionary of reasonable size. Even a 5 word pattern from a very modest 10000 word dictionary gets you 1e20 possibilities, and it isn't too hard to use a 50000 dictionary. You might even learn a new word....
@alan brown
You are presenting a false choice. The contention being that because dlink were/are dicks that the security researcher isn't acting like one here. My post made it very clear in the very first sentence what my thoughts about dlink's behaviour was.
If I had criticism of the first 8, it would be that he didn't disclose them for far too long a time. But I stand by my other point on the final zero day issue dump. He has a good argument in claiming that their security patching isn't up to snuff. Dumping 8 vulnerabilities after months of inaction would have made that point very well, but on the last one he had given their or droids an out. You now watch them deflect the legitimate concerns we all have with guff about irresponsible disclosure that anyone could be the victim of.
> No, I think you missed the bit where he gave them six months to pull their fingers out on eight other vulnerabilities but they just sat there hoping he would go away.
Firstly, dlink are being dicks by not patching security vulnerabilities in a timely fashion. Nothing I say below detracts from that.
On those 8 vulnerabilities, as long as he warned them that the vulnerabilities would be publicly disclosed (not clear from my reading of TFA), he has done exactly the right thing.
On the latest one (with no vendor notice), I'm afraid to say he is being a dick. Even though past experience it would seem unlikely to receive a prompt patch, you just allow the vendor to argue that irresponsible disclosure put customers at risk, side stepping their responsibility to have a secure product and promptly patch security flaws.
Your ADSL is 24? What do you live in the storeroom at the exchange? When I lived 150m from the exchange I got 22.8. Since moving it is closer to 6.
Also, that 100Mbps isn't happening when there is the slightest whiff of contention.
Also, here in the real world, 4G data allowances are sadly still a thing.
@def
I've definitely seen worse. The per user hash and thousands of rounds do prevent precomputed attacks and would certainly up the cost of any attack on your site. The hash iterations are there primarily to multiply the effort per guess (75K times in your case). That is obviously important but it is based on an assumed CPU time per iteration. You are somewhat limited in your iterations by the capacity of your own server (eg, it probably couldn't be a million iterations or your own server would be too unresponsive). And you are limited to the performance characteristics of a general purpose CPU. The attackers may rather use a GPU cluster or even an ASIC and be able to compensate for the additional rounds.
Other approaches try to max out some other resource (eg RAM). If a given guess expanded out to say 100MB then the idea of tens of thousands of parallel guesses isn't practical.
At the end of the day, use a framework. What you're doing is terrific for learning but it is so easy to stuff up (eg how random is your salt actually). I like the common password idea. We've done something similar. And minimum length is pretty much the most important metric. Mixed case/symbols/digits all simply serve to make your password hard to remember and given people use common substitutions (a/@ etc) they tend to add only limited additional security in practice)
Checkout scrypt, bcrypt or argon2 to handle password storage though rather than something bespoke. It will otherwise end in tears
Disclaimer <- I am not a security guy either
> it is possible to use multiple encryption programs in series (eg use 7-Zip to create a password protected Zip file then use ccrypt to encrypt the Zip file then use OpenPGP to encrypt the output from ccrypt.). Done properly there is no way of recovering the original message without knowing the keys even if one of the programs has a backdoor.
Also your idea whilst stopping attacks on specific ciphers does bit assist when said TLA compromises your RNG.
> Why do people who vaccinate their kids care about people who don't?
1. Vaccines work really well to boost your kids'immune systems to fight of some pretty horrible diseases. Really well, but not 100%. You can be vaccinated against say whooping cough but still catch it. Your odds of catching it are much much lower but not zero.
So...
2. Herd immunity means that if less your 'herd' is carrying the virus then you are even less likely to catch it, so that's nice.
3. A very small percentage of the population cannot be immunised. Consider cancer sufferers on medications that suppress the immune system. Also newborns under 6 weeks fall into this category. Their only protection really is herd immunity (newborns might get something via breast milk but it isn't enough). Some people may also be allergic to some ingredients used in the vaccine or as stabilisers or as preservatives, so take them away as well.
4. Treating the disease is massively expensive. Doctors, medications and hospital beds are a financial burden on society and it is frustrating when the majority of cases were cheaply avoidable.
5. Many of these diseases cause long term disability in the survivors and society must pick up the tab on that too. Think polio and even things like rubella can easily kill an unborn child or otherwise cause deafness and heart issues if contacted by a pregnant woman (see point 3, you can't get vaccinated whilst you are pregnant)
6. If you choose to not vaccinate and heaven forbid find yourself watching your child struggle for breath plugged into a million machines or worse, you will have to live with your decisions.
> The botnet was used to launch distributed denial of service attacks by spamming out HTTP GET requests until website connections crumbled under the load
I would have thought that a slowloris DDOS would have been more effective from a mobile device and much harder to detect.
I don't imagine such a patch (for the attack vector) involves pushing anything to a phone. More likely to be patching their automated scanner for their play store with some heuristics to flag up such techniques. But criticism about the difficulty Android manufacturers seem to have in promptly providing patches is definitely warranted.
> And where the fuck are the people at GHCQ when we need them?
Er, 'bout that. Maybe you don't want to look at where the Wannacry miscreants stole that exploit from. I'm sure GCHQ would love to give them a stern talking to, just as soon as they finish handing over all the security researchers who have been assisting in other investigations.
uBlock origin (for example) is on github and is GPLv3. The moment they stay any funny business will be the same moment the project gets forked. Whilst I'm sure they would appreciate your donations (and need some), the amount they actually need to survive and even thrive works out to be a very small amount by a very small percentage of users.
Asking "how does this thing make money" is never a bad idea though.