Posts by Michael Wojcik 12304 publicly visible posts • joined 21 Dec 2007
I find SMS tiresome, but my family and some friends and businesses prefer it, so I go along. I draw the line at OTT messaging services, though, particularly commercial ones. If I ever do need a more-secure not-actually-instant-but-possibly-lower-latency-than-email message service on my phone, I suppose I'll use one of the open-source implementations of the Signal protocol.
I feel the writers of Angel weren't always sure what they wanted to do with the show, and the character arcs sometimes feel a little forced. And, of course, some episodes are stronger than others. But there's a lot of decent stuff in it, and sometimes it could be genuinely moving or really quite funny. ("Evil hand!")
Indeed. Anyone who doesn't remember this episode has no right to write anything about BtVS.
An aside: My wife was watching NCIS reruns the other day, and "Kill Ari, Part 1" came on. That's the tortured, overworked, maudlin, ham-fisted one after Kate is killed, and the various other characters have imagined conversations with Dead Kate. It's like an ill-conceived film-school project. And I couldn't help but think of the Buffy episode "The Body", which deals with the death of a major character and does it so very, very much better.
proof of stack
Proof of stake, I think you'll find. I'm not aware of any stack-based cryptocurrency value metrics.
(Though, curiously, in the cryptocurrency context, there's a quite interesting use of the queue metaphor. Ross Anderson, Mansoor Ahmed, and colleagues at the Cambridge Cybercrime Centre have shown that the Clayton's Case model of FIFO tainting is useful in tracking stolen cryptocurrencies.)
it is fine for watching videos
Well, yeah. The base-level built-in video in my nine-year-old Thinkpad is fine for watching videos.
I spent many years watching videos on NTSC televisions, with 483 scan lines and (just under) 30 interlaced frames per second, and a rather casual attitude toward color. That worked fine, too; I was able to see and comprehend the image, so I could follow along with the narrative. I always thought that was the point.
In my callow youth, I even found it acceptable - indeed a bit exciting - to watch video on a black & white NTSC set. I recall enjoying any number of monster movies and thrillers and the like in that format. It wasn't 4K, but somehow we muddled on. Well, what did we know?
They may be useful for non-crypto compute, but as far as I can tell no one has embraced GPU for production compute
CPU-GPU architectures are pretty common for high-performance scientific computing, and for running convolutional neural networks as part of "deep learning" systems. There are certainly non-crypto production applications.
Granted, there aren't a lot of CPU-GPU applications for general business use, which as you say is typically I/O-bound. But even for traditional business there are potential applications such as Dynamic Stochastic Vehicle Routing, which is of interest to many firms that deal in logistics.
I don't know if all the downvotes are a reaction to the anecdotal nature of your post (which seems a bit unfair, since you were explicit about that), or sour grapes, or just general hostility toward cryptocurrencies. But for the record, while I'm not a fan of cryptocurrencies and never invested in them, I don't see any reason to be angry at someone who did, and timed the market well enough to make a profit.
As AC wrote downthread, it's speculation, and sometimes speculation pays off. Personally I'm a cautious investor - I'm too lazy to try to do well at any other strategy, and I avoid gambling because I'm afraid I might like it - but if someone else wants to take a chance with some of their disposable income, that's no skin off my nose.
Assuming they're not thereby supporting something I feel is immoral or some such, I suppose. But when it comes to that I expect my 401(k) portfolio probably includes Nestle and other corporations with rather vile behavior, and tu quoque aside I'm reluctant to cast a lot of stones.
There is one real and useful thing that utilizes the principle on which blockchain is built
There's one you know of, you mean.
Mercurial also uses Merkle trees. The QNX Merkle filesystem uses Merkle trees, as does the Bazil filesystem, and ZFS, and a bunch of others. Some candidate post-quantum signature schemes, such as XMSS and SPHINX, use Merkle trees.
Maybe you should do a few minutes' research before making sweeping claims?
the blockchain is mind-bogglingly inefficient requiring huge amounts of compute to achieve bugger all
That's true of large proof-of-work applications built on blockchain, such as Bitcoin. It's not necessarily true of all blockchain applications.
That said, I too think blockchain is wildly overhyped. There are some potential valid use cases for Merkle trees and other chained-hash graphs, but the attributes popularly attributed to blockchain (decentralization, etc) rather miss the point. The real advantage of a Merkle graph is that you don't have to recompute the verifier over the entire domain for each insertion. There are various applications of such a primitive.
That's not fair. Smart contracts are also an opportunity for stealing massive amounts of money. Like tens of millions of dollars in a single attack.
Karen Levy and others have argued that smart contracts are not contracts. As currently implemented, they're not very smart, either.
It works like this:
1) User Experience
2) User Interface
3) UI Design
4) Development
You left out the User Interaction Model, which arguably is more important than UX. And the whole thing has to be an iterative process if you want a decent chance of producing something usable.
That said, the key phrase in the article, for me, was "users complain that designers never watch what they do". The "never" isn't true, but "rarely" would probably be accurate. There are a number of well-known user research methods that involve looking at what users do, such as user ethnography and contextual inquiry.
When designers fail to do appropriate user research, it may be because they're lousy designers, but it may also be because no one wants to pay for proper design. Proper design involves significant user research involving multiple methods, in each cycle of revision.
$4500 rent on a small apartment vs $200k buying you a large house outside Sillycon Valley is a bit of a no-brainer
$200K? In much of Michigan, you can buy a large home for $100K or less. Property values have improved a lot since 2009, but they're still really low compared to most of the country.
Mildly adventurous hipster types could buy mansions in Detroit for five figures. A quick Zillow search turned up dozens of 5- or 6-bedroom historic houses for $100K or less. The Lansing market is healthier, but just as an example there's a historic brick 4-bedroom, 3000 sq ft home in Jackson for sale at just under $100K. And Lansing has a lot of IT workers, including recent grads from Michigan State and the other nearby universities.
In Flint? Well, if you like that sort of thing, here's an attractive 4-bedroom storybook-Tudor in a residential neighborhood for $60K. Or less than what many people around here will pay for a pickup truck.
And frankly, Michigan is quite nice to live in, in many ways. Generally low cost of living (except frickin' auto insurance, which alas is the highest in the nation). Very little urban sprawl. Tons of outdoor activities, thanks to all the forests and lakes. Excellent local foodstuffs. And if you're not some sort of feeble wuss, winters aren't bad at all - I'll take a Lansing-area winter over Boston's or New York's any year.
So, yeah. Michigan and the rest of the Rust Belt would have a lot to offer employees. But Amazon was never serious about going anywhere except the sort of coastal urban areas its execs want.
Worse yet, some of those sites limit the password to under 8 characters. It's almost like they are using an old miniframe* with a web front-end slapped on it or something
Not an excuse. See my post above: It's trivial for a front end to overcome this sort of limitation in the backend system. You hash the password, transcode it into the backend system's allowed character set, and truncate if necessary. The attacker still has to find a prefix collision.
I believe RACF has a password character set of at least 64 characters, so you can use Base64 tweaked for EBCDIC and encode 48 bits of entropy in an 8-character password. That's decent; it'd take quite a lot of resources to find a preimage for the first 48 bits of an Argon2 hash.
When you see a web front end that only accepts 8 character passwords, it's a sign that the application developers don't understand security and couldn't be bothered to find someone who does.
Another reason why your email address is your username is A Bad Thing.
That's highly dubious. Kirckhoff's Principle applies: assume everything not part of the secret is known to the attacker. Otherwise you're just adding a small amount of hard-to-manage entropy to the key.
If not using an email address as a username is providing you with any significant additional security, then there's something very wrong with the security of the system you're using.
They have already stolen the password, it's just that it's in an encrypted form
Sigh. Hashing is not encryption.
While there are certainly cases where password verifiers are encryptions of the plaintext password, it is much more common, and greatly preferred, to use verifiers which are derived from the passwords in a manner which cannot be reversed except by brute force.
Salted cryptographic hashes are often used for this purpose,1 but for years now we've recommended password-based key derivation functions PBKDFs such as PBKDF2, bcrypt, and Argon2. The best PBKDFs for this purpose are the ones which are designed to be both compute- and memory-intensive, making it difficult to execute them quickly using GPUs or custom hardware.
Aside from that, your description, while it describes offline password cracking correctly in broad terms, is rather behind the state of the art. Attackers won't try possible password-character combinations in order; they'll use dictionaries of known common passwords first, and then try less-likely variants. Often they'll have precomputed rainbow tables to speed the search. And for offline attempts, they'll be attacking a database of verifiers - verifiers are rarely sent over the network, so it's unlikely an attacker would have have "intercepted it".
Of course, some applications continue to use trivially-broken verifiers, such as unsalted MD5 hashes. A Google search has an excellent chance of returning the preimage for an MD5 hash of an English word.
1And before that, other things. UNIX originally used an encryption-based mechanism (first using the M-209 cipher and then a modified version of DES); but it used the password as the key to encrypt a fixed block, and then chained that for a number of rounds, injecting a salt value into the cipher. So the verifier was still in effect the output of a cryptographic hash of the password. NTLMv1, on the other hand, used an algorithm so stupid I can't even bear to describe it.
why does one of the most commonly used cloud services, office 365, limit passwords to just 16 characters?
Because the Microsoft Office 365 team are a bunch of idiots, presumably. (I note that Microsoft Forefront Gateway also used to have this problem, and may well still have this problem. It's unacceptable.)
Fortunately, at my place of employment we use SAML authentication to Awful 365, and our authentication mechanism allows reasonable passphrases.
There's no reason to ever restrict the passphrase length to any unreasonably short value for a web-hosted service. Even if the backend system has a password-length restriction, you can create a verifier using a decent PBKDF (bcrypt, Argon2, etc), then transcode that into the character set accepted by the backend system. You may well have to truncate the verifier, but that doesn't help an attacker all that much because they'll still have to find a prefix collision, and good PBKDFs are expensive to compute.
rules about changing every one to three months, demanding mixes of upper case, lower case, special characters, numbers, no repeated characters
Aside from the last, none of those should be any real impediment to using real-world passphrases. It's quite easy to construct natural-language phrases which "naturally" (i.e. in a manner familiar to a reader of that language) include mixed case, punctuation, and numerals. And memorizing such phrases is not particularly difficult, so having to change them periodically isn't a problem either.1
One technique is to choose words at random from a dictionary until you can assemble a phrase in the style of a newspaper headline; then add a numeral and some punctuation. For example, here's a few I selected from a list of words I extracted at random from aspell's US-English dictionary:
Norrie's, cashier, unstable, syphilis, unmanageable, newsreel, show
I just chose those from the first screenful, in about 10 seconds of looking. From those I could make:
Cashier Norrie's unstable syphilis unmanageable; newsreel shown at 11:00
That's shouldn't take much effort to memorize, and the use of capitalization, punctuation, and numerals is natural.
Now, that doesn't have a ton of information entropy. With Shannon's estimate of around 1.5 bits of entropy per English letter, we have only "about" 110 bits at best from the text. Since the capitalization is natural, an attacker who knows our scheme (Kerckhoff's Principle) can guess those, so that adds nothing. Similarly the use of numerals and punctuation isn't contributing a lot.
Now 110 bits still sounds pretty good (much better than that 8-character NTLM minimum password), but some experts think Shannon's estimate is too high in this context, particularly if attackers apply well-trained models to the problem. Someone who duplicated my aspell-based dictionary (around 150K words) and tagged them with part-of-speech information, then trained a model on plausible headline-style phrase structuring, could narrow the search space down quite a lot.
Still, if you really want passphrases you can memorize, you can accommodate quite a lot of those largely-pointless password restrictions. The tough ones are length limitations and especially idiotic prohibitions like the one on repeated characters.
1And, of course, you can always use a passphrase manager blah blah we've all read a thousand posts pointing this out.
Of course you'd better have a good backup strategy!
Yes. And for many people, it's also important to have an inheritance strategy, so that your heirs can get into at least the important accounts in the event of your unexpected demise. This is a major problem for many families, and one that most of the password managers I've looked at don't handle very well.
when someone from law enforcement starts asking you questions: shut up
Good lord, yes. Any defense lawyer will tell you this. So will many prosecutors - Kevin Smith says it routinely on Popehat, and he's a former prosecutor. So will plenty of law-enforcement officers, who readily admit that they get a lot of convictions and plea bargains based on unfair interrogation tactics.
James Duane has a great lecture on this topic, in which after giving his opinion (never, ever, ever talk to the police without representation), he turns the mic over to a career law-enforcement officer, George Bruch, who proceeds to tell the audience the same damn thing. Bruch points out that, for example, the police are quite happy to interrogate someone for several hours, because they're getting paid to do it.
That video should be required viewing for anyone in the US. They should show it in public schools and on international flights entering the country.
Because taking a long time works in the prosecution's favor. It makes the defendant much more likely to agree to a plea bargain, which is how most successful prosecutions end. It makes it less likely the defendant will gain sympathetic mention in the press by the time the case goes to trial, if it ever does. It saps the defendant's resources.
Under the US adversarial system, the prosecution's job is not to seek the truth or achieve justice; it's to secure a conviction or a guilty plea. I've known some prosecutors, in various positions, who were actively concerned with justice - but it's not a job requirement.
There's a reason why the grand jury system is enshrined in the US constitution - specifically in the Fifth Amendment, part of the Bill of Rights. As Gareth wrote, it has its origins in English Common Law (specifically in Henry II's transfer of power to royal courts and in Magna Carta); but its deployment in the US had a somewhat different purpose.
In principle, grand juries offer an important check on prosecutorial power. That's why they have investigatory powers - so that the members of the grand jury can determine whether prosecution is legitimate, or a case of overreach, political oppression, personal vendetta, subornation, etc.
Unfortunately, in practice, statistics show that grand juries are incredibly unwilling to refuse to indict. In 2010, Federal grand juries returned an indictment in 99.99% of cases. It's just one of many problems with the US prosecution system today; other major ones include the two types of "chickenshit prosecutions", the trend for the various state's-attorney offices to serve as stepping stones to other political positions; and extremely excessive sentencing laws passed by cowardly legislators who don't want to be seen as "soft on crime".
The idea of a grand jury system remains a good one, though. Other countries which have dispensed with them aren't necessarily paragons of judicial virtue.
Are ... are you suggesting there weren't malicious, criminal, antisocial vandals before now? Or before the modern era? Or at any point in history?
Because I'm pretty sure we've always had people like this. At one point in time their exploits might have been largely limited to, say, accusing single women of witchcraft and burning down the odd barn; but that's just a question of opportunity.
Yes, though it's worth noting that what finally got Vaughn was a mistake in OPSEC - an area where he was generally quite careful. He used one of his hacker identities for an online gaming site, and tied it to a mobile phone number; and then later that site was itself hacked and user records were released, which eventually led to Vaughn's identity being compromised.
It's quite interesting, really. Krebs's blog post on the subject (linked in the article) is worth reading.
More precisely, what we have here is what's often known as a "complex" sentence, where an independent clause is interrupted by a dependent clause. You're correct that the dependent clause is in apposition, in this case to the subject of the independent clause. A phrase (which of course can be a clause) in apposition acts grammatically as an adjective; here it modifies the proper noun "Duke-Cohan".
While someone could make the argument that the antecedent of the pronoun "he" in the dependent clause is ambiguous, it would take a deliberately resistant reading to make it anything other than "who", which as the subject of the dependent clause clearly has as its antecedent "Duke-Cohan".
This is all quite straightforward English grammar, and competent readers of English ought to have little difficulty with it. Well, relatively speaking, considering it's English - a language with notoriously irrational grammar, usage, inflection, and orthography.
That would be tricky, since giant pandas are (alone) in a different subfamily of ursidae and not closely genetically related to kodiaks or other ursinae. Quoth the 'pedia: "Nuclear chromosome analysis show that the karyotype of the six ursine bears is nearly identical, with each having 74 chromosomes, whereas the giant panda has 42 chromosomes".
That's not to say you couldn't snip genes from kodiak DNA and wodge them into the giant-panda genome somewhere, but we're not talking something straightforward like liger-breeding.
Frankly, it'd be cheaper to hire a good PR firm for black bears. Those bastards are successful.
Australia has a total land area of 7,659,861 sqkm (around 2,969,607 sqm)!!!
Australia's land area is surprisingly close to the total land area - i.e. not counting surface water, of which there's another couple hundred thousand square miles - of the contiguous United States (i.e. the contiguous 48 states plus Washington D.C.).
Obviously if you add in Hawaii and Alaska there's a bit more land area in the US. Really Hawaii is within the margin of error; Alaska adds about another 20% to the US land area.
Of course there are a lot more road miles here than in Australia. Particularly if we count the "forest roads" built and maintained by the US Forest Service, which has around 375,000 miles of them. (That's nearly 8 times as many road miles as the US Interstate system.)
I'd go further, and say it's not a matter of how much time you spend thinking about the work, either.
A laborer produces a satisfactory result at a satisfactory cost, or does not. If I have an employee who only works one day a week but is twice as productive as the average employee, why would I complain? I should be able to tell if I'm getting good value for my money. If I am, good; if not, I need new employees, not surveillance. (For one thing, that's not going to improve quality.) And if I can't tell, then that's my management processes at fault.
The proof of the pudding is in the eating. Beyond examining the results, management can fuck right off.
Of course, the real problem here are would-be Big Brothers and vile bastards like Konanykhin who enable them.
So are we saying here that image analysis software does nothing at all with shape?
The research here shows that a particular handful of image-recognition ANNs, which share a number of architectural features including depending heavily on stacked CNNs, are more sensitive to texture signals than to shape or edge signals.
Drawing a broader conclusion is speculation.
My instinct is that this should have been obvious from the mathematics underlying CNN's. Yet apparently no one picked it up.
Or was it that people did, but hoped no one would notice?
People did, and published research about it. It's just that research was largely ignored by lay readers, image-recognition-technology boosters, and the press.
As usual, though, the Reg commentariat assume they're smarter and more knowledgeable than the people actually working in the field.
It's a bit hypocritical to demand your own privacy without allowing a law enforcement agency some of their own
That's the stupidest claim I've read all week.
There is no a priori reason to believe natural rights attach to institutions. Nor is there any significant trend in US mainstream political philosophy, legislation, or jurisprudence that would assign such rights to institutions, except where they are inherently institutional (e.g. freedom of the press), and certainly not to government departments.
And even if it were otherwise, it would not be hypocritical to postulate a distinction in how rights are assigned to individuals and institutions.
Anything important to me - I back it up myself.
Early in my career, I was working at IBM and had a PC RT (IBM's first commercial UNIX workstation) running AOS 4.3 (IBM's BSD port for the RT). The machine had a pair of 40MB drives.
Someone found a 70MB drive in one of our Rooms Of Discarded Stuff. (I was at IBM's Kendall Square building, which also hosted the Cambridge Scientific Center, so the site was full of weird experimental hardware and random used bits and pieces, stashed willy-nilly in unused offices.) So I figured I'd give myself a 30MB upgrade. I was going to take the machine down to put in a faster CPU daughterboard anyway.
Since I was going to repartition, I backed all my stuff up to QIC tape. Then I shut the machine down, swapped the 70MB drive in for one of the 40MB ones, booted to the AOS install tape, partitioned the drives, installed the OS, and went to install from my backup tapes.
The backup tapes were unreadable. I don't know why; they were reused and may have been too old, or I may have messed up with my mt and tar command lines; or there might have been something wrong with the tape drive. (It read the OS install tapes, but like an idiot I hadn't tried writing a tape and reading it back.)
All my actual work for IBM was in source code control on the AFS network filesystem, of course. Even at that age I wasn't a complete idiot. I always operated on the assumption that my workstation might die at any moment, and the work I was paid to do had damn well be preserved somewhere else. And some personal stuff I really cared about had been backed up to floppies or whatnot. But I lost a bunch of personal projects I was goofing around with after hours, like my personal X11 window manager.
It was a painful lesson - I probably spent half a day trying to get those damn tapes read. But eventually I accepted it.
(Then, years later, I had a laptop hard drive suffer catastrophic controller failure while I was in the process of backing it up. All I lost that time was a few days' worth of emails, because I was pretty vigilant about keeping stuff backed up. And checking those backups.)
LTO8 is about 20TB per tape so not that many tapes, even if they are a hundred bucks a pop.
The real cost, I think, would be in paying people on site to physically secure those tapes off-site. I suspect that's why VFEmail didn't have off-site physical backups; it was a relatively small operation, with servers in datacenters on multiple continents, and probably didn't have the budget to pay people to physically load blank tapes and put filled ones in storage.
It's feasible for a handful of administrators to run lots of virtual servers in datacenters around the world. It's considerably more expensive as soon as on-site human labor gets involved.
And running those sorts of backups remotely probably wouldn't have been feasible either, due to latency and bandwidth constraints.
That doesn't mean data like this shouldn't have off-site physical backups, of course. I just think the economics are difficult. How much more can you charge your customers to cover those backups without having an unsustainable fraction of them switch to competing services? Users historically have not shown much willingness to pay extra for security.
they might have wanted to permanently yeet something that was on those servers
I agree - this looks like someone specifically wanted to destroy something specifically hosted by VFEmail. It may well have been simply the email archives of a single user, or a small number of users, and the attacker just wiped everything for simplicity and to disguise the true target.
It's interesting that the attacker apparently had multiple sets of credentials for the different servers; that suggests a sustained effort, with an initial phase of gathering vulnerabilities so the attacker could hit everything in a brief campaign.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
