Posts by Trevor_Pott 6991 publicly visible posts • joined 31 May 2010
You can RDP into the free hyper-v server itself. THere is no classic GUI, however there is enough of one to be RDPable and it presents two CMD.EXE boxes for you to work with. (Just type powershell into the one to turn it into a powershell console.)
It's free to try and free to use. You can even run it on VMware with minor modifications for testing purposes (links at the end of the article.) Go give it a boo!
I think the idea of a crypto system that relies on randomness and ever-increasingly large primes is fundamentally flawed. It's flawed because the system simply relies on entropy to be safe. "It's harder to brute" means nothing when humans are not nearly so different as they think. There are seven billion of us; there are an incredible number of us who chose the same "unguessable" password, or password patterns.
So while some of the techniques you mention do certainly raise the barrier to entry for the crackers, fundementally we need a chance in how we approach crypto. What that approach is, I honestly can't say. I'm not a crypto genius. We need a revolution that is to crypto what general relativity was to newtonian physics. That takes an Einstein. Someone who can think so far out of the box they redefine said box and it's interactions with the universe.
Until then, the bad guys will continue to get better and we will continue to be even more vulnerable. Thus my call for "trustworthy by design." Don't assume that ANYONE is trustworthy when you design your application; including yourself or whomever is going to run the application.
Do not rely on cryptography alone to secure data.
Establish and maintain data custody at all points where the only person(s) with access are those who the creator of said data authorized explicitly. Any hole that a "bad guy" can slip through, a "good guy gone bad" can get through even more easily.
In practice, the above would also be coupled with a random salt.
Except, in reality virtually nobody seems to salt their passwords hashes.
As for salt cracking, there are at least three good methods I know of:
1) Crack 2 (or more) passwords by brute force. Find what's the same and take that as salt. Attack rest of hashes.
2) Sign up for the service and use your known password to attack the hash to determine salt.
3) Find an e-mail address associated with a password hash that you already know the password to (because you cracked that user's password on another site and we all reuse passwords.) Use the known password to attack the hash and determine salt.
These are just the ones I know about and I am not a security expert.
Now, you're correct in that huge key sizes and large character values with password requirements that force the password to be something humans can't remember stands a chance of surviving even a trained hashcat operator with a 50-GPU mini-super sporting 12 ASICs for fun. (Which I am seeing more and more of on the cracking scene these days.)
That said: A) nobody uses those in reality. B) It still doesn't protect you against US.gov. And again, there are supposedly salt attacks out there I haven't heard of - I'm not cool enough to be in those password cracking clubs, you see - so I wouldn't be so sure about the security of hiding behind large numbers.
Dan Goodin at Ars Technica has a series of articles on cracking passwords that you really should read. Some of what you say is true. Some of what you say is...out of date. I'd have agreed with you a few years ago, before Hashcat, modern pattern matching, anti-salt techniques and GPU + ASIC mini-supers.
The problem is that brute forcing a password is only actually a requirement for a very small number of passwords in any given list of hashes. Our techniques for cracking password hashes and encryption have evolved so far beyond brute force that mere entropy is not longer a workable measure of password difficulty. Instead, randomness is becoming highly critical; passwords cannot be allowed to match any known pattern.
Whatever the handwaving, the end result is that your passwords are encrypted and stored in the LastPass cloud. When I download the client to a new computer and log in with my LastPass master password I instantly have access to my full database of password on that new computer. I can log in to anything I want.
That means that there is enough information on the LastPass cloud to reconstitute my username and password for every single website I have stored in there. There may be layers to the encryption, but encryption can be - and is - broken. I'm sure you're next going to trot out some obscenely long period of time it takes to brute force whichever set of algorithms were chosen. Let me save you the trouble.
You know and I know that encryption and password hashes both are rarely brute forced anymore. There are about eleventy squillion techniques ranging from the humble dictionary attach to pesudo-brutes using "common patterns" combined with various advanced dictionaries that will solve the overwhelming majority of decryption tasks. Brute forcing is rarely every necessary.
In a lot of ways, LastPass is even more vulnerable than a simple database of hashes because of the vulnerability of that master password. The Master Password has to be something a human can remember in order for the system to work. So even if the encrypted container/hashes/what-have-you on the lastpass side can't be bruted, the master password is highly vulnerable and thus so is everything it protects.
Look, I"m not bashing LastPass here. I wouldn't use it unless it kicked ass. It's probably the best defence we currently have. It is, however, not remotely perfect. If nothing else, it is vulnerable to the feds. They could walk through the LastPass defences like a hot knife through butter if they wanted to and there isn't a damned thing anyone can do about it.
So long as enough information exists in a a cloud service stored on United States soil to reconstitute my passwords enough to log in to online services then those passwords - and everything they are meant to protect - belongs to the United States government as surely as if I had written it all down on a sheet of A4 and left it in my pocket whilst crossing the border.
The LastPass hashes live in the cloud. All you have to do is download the client, feed it the password and it will fetch the hashes and install them locally. Your master password is not stored on the LastPass cloud, but a hash of that password is, so that you can authenticate and then download your password information.
That makes the whole thing a pretty damned tempting target. A hash is almost as vulnerable today as a plaintext password. It's pretty terrifying how quickly a well-trained cyrpto-cracker can wade through a list of millions of hashes and crack upwards of 95% of them in a few days. We like to ignore it, yet it happens with alarming regularity.
It doesn't matter if the hashes are stored in a database as hashes in the traditional sense, or an encrypted file filled with password info (which is probably worse, as it's a single attack point.) The point is that your information is wrapped up in increasingly easy-to-defeat encryption then stored centrally, alongside everyone else's.
As to storing them on my local machine being somehow "safe"...tell me, sir, are you 100% positive - willing to bet your finances, your job, your life on the fact - that your local machine is not compromised by malware? If you are then I invite you to please write an article for The Register detailing exactly how you know that. Nothing is really safe, it's just a question of which systems are worth the value to attack.
8.11 for Workgroups does not fix any bloody issues. A Start button that brings up the Start Screen? *bzzzzzzt* Wrong answer! Explorer (and so much else) still has Ribbon bars? *Bzzzzzzzzt* I could go on - at length - but 8.11 for Workgroups doesn't actually address any of the concerns that the general public raised. It was a shitty token gesture designed to seem like outreach without doing a goddamned thing to change the real issues.
8.11 for Workgroups is Microsoft's way of "doing something" that is in fact nothing so that they can get on their horse a month later and scream "but we did what you want!" They'll claim "persecution" and will start a P.R. war whereby they blame their opponents (Google, Amazon, etc) for "fighting dirty" by funding (or arranging airtime for) people who continue to highlight legitimate grievances with Windows 8, or the general "trustability" of Microsoft.
8.11 for Workgroups is a mirage. A handwave to befuddle the gullible and give them justification for a protracted campaign aimed at silencing dissent. Microsoft has thrown power users under a bus and done so on purpose. They've done it for the same reasons Apple has. It will come back to bit both of them in the ass in short order; on that day, I will give out free popcorn. Until then, well, Windows 7 doesn't end support until 2020 and Cinnamon works just fine for me...
Because you often have to set the damned thing up using IPMI or other such things to get them remotable *before* you can get remote access even working. Other times you want to work on a file that lives on the system without dragging the file off the system or finding some way to get access to the local file storage on that system from your remote station.
In a unix world the shell is all. I just need one port open and I can get through to do my administration. No additional services, no additional windows, no nothing. Just one black box per server. In the Windows world I have to strip the bloody server naked and let all the bits hang out so that I can even edit a text file! WHAT. THE. FUCK.
Microsoft still lives and breathes eggshell security. Harden your edge, but behind that edge you need to wander around with your WMI, SMB and $deity only knows what else hanging out just to do basic administration! This is in contrast to a Linux world; there I have a hardened edge and layers of security - from obscurity by changing SSH off default ports to things like Fail2Ban to lock out attacks to layers of logwatching - that lock down a server INSIDE my network just as though it were facing the internet itself with no deprecation in usability or administerability.
Look, I don't buy eggshell security. Securing the edge is not enough. A) the edge is coming to you. IPv6 will eat your family. B) Something behind your edge is always compromised. Wee willy wonka the lobotomised salesdrone really likes barney BDSM porn and he's perpetual infected. Meanwhile, you forgot to firmware update your IPv6 lightbulbs and half of them are supporting malware that's probing your infrastructure from the inside.
So no, I don't want to use the PowserShell ISE. This doesn't solve my problem of opening a test file on the remote server without opening more holes. Not only that, the damned thing is Windows only; I stopped using Windows as my primary desktop environment ages ago. Have you seen Windows 8? Microsoft lost the plot and their corporate ego won't let them regain it.
Powershell is a necessary evil. It is unquestionably the future of administering Windows Servers because Microsoft says it is the future of administering Windows servers. What it isn't is good enough. It's all sorts of bitchin' and powerful but it is still designed solely for cleanroom sysadmins with their procedure manuals and testlabs and 3 month concept-to-implementation timeframes.
It is not something that lets me log in to a system and fix the fucking thing. It is a configuration tool that I see akin to "the Cisco IOS for Windows Server and associated applications." You don't log on to a CIsco router and just fix it. You never make live changed to a production unit without simulating and testing and layers of covering your own ass.
PowerShell is the same thing. You build your PowerShell config carefully in your cleanroom and then you push it out to the system and set that system's state. PowerShell really, really wants to be Puppet when it grows up. Given the awesomeness of Puppet, DevOps as a model for enterprise and commercial midmarket IT and so forth...that's great! Go Microsoft!
Systems administrators for smaller shops where budgets, staff and every other conceivable resource are as minimal as possible are firefighters. When you fight fires all day long, you want this. This is what Bash and the associated bog-standard utilities are.
When I'm in the middle of trying to put out 50 fires at the same time and you tell me to use PowerShell you are telling me to put out a burning building with this.
PowerShell is not a way to administer a system. It is a way to configure it. They are still completely different things. You can get yup on your horse and sneer disdainfully at the rest of the world and say asinine things like "well, if those sysadmins were any good, they'd never have fires to put out because they'd have adopted DevOps and be doing everything with huge pre-planning and simulation and testing." I'm sure you've thought it more than once reading this comment.
The reality of the matter, however, is that the majority of systems administrators simply don't get that option. They aren't in control of the budget. They don't set corporate IT policy. They don't have much control over any aspect of their jobs, really, and they simply do as they are told or they get replaced. They are told what to do not by some senior IT person who is themselves responsible for setting policy, but by the accountant, the sales clerk, the marketing wonk, the CEO and the janitor.
In most companies, sysadmins are the lowest ranking member of the corporate structure. They are there to serve. To make things happen whenever they are told and they are not expected - or allowed - to talk back. If they say no, they get fired; pure and simple.
In this situation, these people are fighting fires all day. They are fighting fires because they have to make quick changes to live hardware without simulations or a testlab. They need to back all this up (before and after) and they need to manage hundreds (if not thousands) of different types of devices and applications.
They move from device to device, server to server, application to application solving other people's problems in real time. This is why they can't use eggshell security. IT could be months or even years before they get back to a given system and then only because it did something it wasn't supposed to.
Every system they use has to have a complete set of tools on it. They can't wander around remotely accessing the system from their carefully maintained desktop; there may be layers of firewalls, VPNs, and gods only know what else between them and the target system. They may be RDPing in to server then RDPIng into another system then launching PuTTY to manage something because of a series of political and economic decisions taken by the business over the course of decades that isolated that system in that office in this particular way.
PowerShell as it stands today is virtually useless in that environment. Again: it is for configuration not administration. Maybe next version...
No, I can't use the old ones because they aren't ubiquitous. The Text editor *NEEDS* to be part of the CLI and installed on BLOODY EVERYTHING with PowerShell on it. This is why I won't move back to Windows for my unattended servers; the tools I need just aren't there as part of the CLI shell. If I have to start installing a bunch of tools onto my Hyper-V boxes then they cease being simple, interchangeable deployments and start being special flowers that each need attention. EDIT was part of the DOS-style command line for ages. BRING IT BACK.
Perl is good for those raised on Perl. I cut my teeth on VB and PHP. I'm not a developer by trade, and while I can read Perl, I don't think in Perl. I have coded so much PHP in my life that I think in PHP. I don't know of any other way to explain it; every other language I use is one for which I have to build a translation matrix in my head and map that functions of that language back to PHP functions that are part of my mental "muscle memory."
I can go months without using PHP and then pick it up again in minutes. If I go even a few days between Perl, Python, PowerShell or other coding stints, I'm pretty much back to square one. I don't know if that makes sense, but that's how it is. I don't have an eidetic memory; if I am going to learn a language it is going to have to be something I use every single day for so many months that it is burned into my synapses. For me, the ONLY things that ever achieved that level are DOS BATCH, HTML, and PHP.
If you want the barrier to uptake, it's that, RIGHT THERE. PowerShell is the bee's knees if you can work with it for 8 hours a day for months on end and you have time to learn, play, explore and so forth. If you manage a heterogenous environment and spend the majority of your time hip-deep in Linux, VMware and DSM (with Windows largely taking care of itself) then PowerShell is a hindrance, not an enabler.
PowerShell is a bitch of a thing to get in to if you only do Windows part-time...and the majority of that isn't "experimenting", it's "putting out fires."
Trevor is weirded out by all the third person references to himself. Also: I'm ambivalent about PowerShell, myself. I prefer flat config files wherever possible. I like to be able to get in with some basic string manipulation stuff that I know knock together in any scripting language (from BASH to PHP) and pick apart whatever the file is. PowerShell is very...Microsoft.
If it has to be "not a flat text file" I'd prefer that all configs be something I can pull and then re-enter as XML - which admittedly is sort of possible in PowerShell - by using the language of my choice. I don't have *time* to learn a new scripting language. Certainly not one as badly documented as PowerShell. (Though again, Microsoft is getting better here.)
I *like* doing my configs in PHP for two reasons: I know the language by heart, and PHP.NET has the best damned documentation on the planet. Replete with examples and a community contribution section where commenting, common use cases and expansion on the functions in the language are integrated into the documentation.
In Linux I can easily knock together a BASH script that takes down a service, runs a PHP script to make whatever changes I need, then lights back up the service. I can manipulate all sorts of stuff in the file system in PHP and basically work in an environment I'm comfortable in without having to learn a whole pile of new stuff.
PowerShell is amazing. It's a great technological achievement and a good way of doing things. But it still doesn't have a command-line text editor. I can't simply *live* in PowerShell the way I can in bash. I have hundreds of servers I have only ever interacted with using SSH and BASH...PowerShell always requires me to pull up a PowerShell IDE or Notepad (at least!) and probably a dozen browser tabs to figure out what the hell I am supposed to do.
There's an element of "Get off my goddamned lawn" to my PowerShell ambivalence. But there is also a sense that the people designing PowerShell are DevOps-style "we're developers that think we're sysadmins" types who design for great big farms of identical machines. They aren't sysadmins who have only a handful of servers and who have to make changes to live systems without 8 days of testing in the lab.
PowerShell is for people who live in cleanrooms. BASH is for people who take cars apart and have grease on their hands. At least, that is how it has seemed to me so far.
But for tossing a few Linux VMs that just wake up, respond to something and go back to sleep it's not a bad little box. It's a lot less of a pain than trying to build some Raspberry-pi-alike box for each function then lashing the lot of them to a pole. Standard software, standard management tools, etc.
It's "good enough" for a lot of things that might have driven me to ARM. Which, really, is the only reason the thing exists in the first place, so it's doing it's job, I suppose...
I've evaluated about 8 different levels of subscription. Most of the articles you'll read are Enterprise E3 based subscriptions, simply because when you spin up a trial that's the version you get. If you have questions about other subscription levels, let'er rip; I've probably used them at some point...
Ah, the cryptonomnomnom. One of my favourite books; and lo: this past month I've taken up with a gaggle of folks who are displeased by "cloud + patriot act" symptom combo. They're building a datahaven: life imitates fiction once more.
Beer, because it's the closest thing to melted gold.
Hi frankg. 2000 called and it wants its understanding of the NT kernel and base operating system elements back. Thanks.
If you'd actually READ my post, you'll note that I discuss that fact that there are tons of features in the OS that are NOT MANDATORY and I even tell you why. I also said that making them mandatory would make a much more secure operating system. Microsoft even makes it; I even discussed why.
The sandboxing you discuss exists. ASLR and about a dozen other technologies exist. The issue - and it's huge - is that they don't make using such technologies mandatory, which is what allows flash to get out. It isn't because the mechanisms to make a damned fine secure OS aren't there. It is because they made a BUSINESS decision not to cut all old software (and thus their entire paying customer base) off at the knees.
Take a Microsoft operating system which has been configured to require all of the security technologies as mandatory for every single application and I would be willing to put that up against anything else out there except possibly Wind River's stuff.
Your willing ignorance to suit your own prejudices not only does you a disservice, it brings a bad name to all who practice the IT arts. There are plenty of damned good reasons to piss on Microsoft's good name. This isn't one of them. Quit fighting battles from a decade ago; you're distracting from the battles that need to be fought here and now.
One of which is to get them to make the very technologies under discussion mandatory, but it is not remotely the only battle that needs fighting. We not need pissing and moaning about how "Insecure" Microsoft's technology is. That war was fought. We won. Can we please get you on the front lines where it counts?
Cheers.
Let him. When greed + copyright clashes with privacy + information security, I vote that greed + copyright shouldn't be the one to win. Those who would blithely sacrifice the freedoms of others whilst diminishing the security of all in order to eek out a few fractions of a point of margin should be tarred, feathered and run into the oceans their brethren polluted beyond usefulness.
The viruses and other malware are the raw, unfiltered sewage. Firewalls are needed only because apps/operating systems aren't particularly secure...excepting that of late they've been a hell of a lot more secure than Adobe and Oracle's products.
In case you missed it, Windows et. al - while by no means perfect - aren't exactly swiss cheese anymore. Microsoft in particular has done a damn fine job of securing their operating system. Without Flash and Java installed, I'd cheerfully browse the net with a plugin-less Firefox on a Windows without anti-malware.
The issue is these vulnerable plugins that live in our browser and allow execution of code with elevated privileges when compromised. In fact, if they would code the damned things according to Microsoft's spec, this wouldn't even be possible to have happen.
The reason that the operating system allows Bad Things to happen is because it needs to maintain a level of backwards compatibility. The reason it needs to maintain a level of backwards compatibility is because fuckwads like Adobe and Oracle refuse to write applications that comply with modern design and security standards. The reason we're all vulnerable is because these same applications don't comply with modern design and security standards. They are the screen doors letting in the internet's filth.
MIcrosoft could make an operating system that had no backwards compatibility. Where you must comply with modern security and design principles. Then we collectively would freak out and wail that the insecure applications we are so very reliant on don't work.
Indeed, Microsoft did make such an operating system. It's called Windows RT. Frankly, given the raft of compromises on OSX lately, and the shocking number of Linux (or SSHd/HTTPd/BIND/etc, if you want to be an anal-retentive prick and try to say that "Linux is only the kernel, not the Distro") major vulnerabilities in the past several months, Windows RT is looking more and more like one of the most secure operating systems ever developed.
We still collectively don't use the damned thing for one simple reason: the shit we actually need to use doesn't run on Windows RT. And the shit we need to use is all broken, insecure and otherwise the cause of our woes.
Adobe and Oracle are like the worst kind of candy pimps. They keep you addicted to their crack so you can't go far, but they beat you senseless and refuse to change their ways, meaning you do nothing but dream of escape. I'm not saying Microsoft's been all that much better; Metro's "Fuck You, power users and people who require actual productivity" interface, that goddamned fucking ribbon, "Always On," Office 365 subscription bullying, licensing shenanigans and even DRM bullshit like "plays for sure" all come to mind. Microsoft is no saint, and I'll not defend the bastards on the whole.
But don't blame the OS. That's the part of this that actually works securely, assuming you are willing to configure it to be secure-only, and live without your self-harming crack.
Since you aren't - and I'm not either - why don't I leave you some resources that (while a little old) might prove valuable?
I hope that helps you maintain your poor security habits with minimal damage to yourself and the rest of the internet. Cheers!
So they've discovered Google FS? I thought that was an off-the-shelf thing at this point. The only real difference is that a proper P2P network would have a distributed "name node" structure (think Nutanix here) instead of the single-point-of-failure so common to the earlier implementations of things like Hadoop.
We're just talking about turning an ISP's last-mile network into a giagantic Hadoop cluster which then connects via a Fat Link to some other gigangtic Hadoop Cluster on some other ISP's last mile. (Well, not actually Hadoop, but you get the idea.)
That's (maybe) okay if you are talking about a "mostly isolated network" like xDSL, but this would play merry hob with DOCSIS-based (cable) modems and infrastructure. Google Fibre as the base? Maybe. But when you're at a Google Fibre level of "to the premises," are you really putting much compute/storage/etc in the individual house? If you were sitting on a pipe the size of the Mississippi, then you'd be a perfect candidate for "as a service" streaming and storage of all your data. Once you've that kind of bandwidth, by $deity's sake, toss your non-unique data into the cloud and let someone else deal with the headache of managing and maintaining it.
I am not against fundamental research, but this does seem as though it won't be a "peer to peer" network in the traditional sense. Interesting theoreticals on a CDN, though.
This is part of a much larger play in a long-term strategic marketing war against Google. The goal here is to gain some insight in to the best buttons to push when trying to paint Google as a privacy-violating cyber-fiend out to stomp on your puppies and steal your wife. When you can't market on merit, viciously attack the other guy with as many falsities and carefully manipulated half-truths as possible!
How very...American. Next up: did you know that the Sentaor for Internetistan is SOFT ON CRIME? It's true, they voted down this bill that would have STOPPED CRIMINALS COLD[1]. Can you afford to elect them? Vote Douchebagus Maximus for cyber-overlord today!
[1]Would have stripped everyone of anything resembling civil liberties, but ignore that he's SOFT ON CRIME.
The difference is price. The cost of this enterprise-standard tech has come down enough for there not to be an excuse for its inclusion in even the most basic of SMB gear. The tech is mature. The pricing is a transformative element enabling far wider adoption than was possible even two years before.
Enterprise vendors have had this for ages, but lots of folks who make "whitebox" kit (ASUS, Gigabyte, Tyan) don't. Or if they do, it is often quite a pricy extra. We're finally at the point that SMBs and bulk-buy folks using whitebox servers can buy IPMI-equipped stuff without pushing virgins into volcanos. It's time we stopped buying the crap that doesn't have lights out management. Send a message to companies like ASUS that if you market a "server board", it isn't okay for it to lack IPMI.
They told me to be blunt and honest. I have no dollars in my pocket for marketing. And a list of experiences both good and bad with Office 365 as long as my arm. Seriously guys, when have you known me not to take the piss out of Microsoft when piss needs to be taken? I also give them an attaboy when they deserve it. *shrug*
Let's just say that Microsoft marketing and I don't exactly see eye to eye. It's not as bitter as the divide between Microsoft Licensing and I, but it's still a hell of a gulf to cross. Ask your questions; you'll get real answers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
