(If you insist on using windows, what about downloading SUA from microsoft themselves? That way you get a working SSH client without trusting anyone you weren't already trusting)
I actually DO care about security and go to great lengths to secure my Windows 8.1 laptop and several physical Windows 2012 servers I maintain. If you know anything about security, it's actually pretty easy to secure a Windows machine.
One of the main reasons I'm stuck with MS is because there are no Adobe products available on Linux. The alternatives suck donkey balls and I hate Apple (too long of a story to get into here). Thus, I use Windows.
Full disclosure, I have several Linux boxes running Mint and an Ubuntu server and I'm actually quite fond of Linux. Unfortunately, a majority of my development is done with Adobe tools so I'm stuck. Give me a decent set of dev tools that mimic my Adobe tools (Fireworks, Illustrator (not Inkscape), Photoshop (not GimpShop), InDesign and now their Edge tools) and I'd drop MS in a heartbeat go 100% Linux.
> Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need to salt them.
Taken from Microsoft's own documentation: http://bit.ly/1juRmCT (Using Bitly because the link has parens and HN sometimes doesn't like that). Microsoft's argument boils down to this: Because they don't provide a GUI to view password hashes they're secure!
People gave LinkedIn and Adobe crap for their leaked password dumps not using a salt (or using reversible encryption!) and yet here we have MILLIONS of Windows installations all over the world doing the same damned thing. What's worse is that Active Directory also doesn't store password hashes using a salt. If your domain admin credentials ever get stolen the attacker is mere minutes away from cracking every damned password.
For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz
The passwords it displays (using the "sekurlsa" module) are from probing the process memory of LSASS.EXE to view cached credentials. So it will only display the plaintext credentials of currently logged in users.
However, this is actually an important exploit / factor to be aware of if you're considering installing software securely on a platform. Is it possible to blast through account credentials with a small method like this? I certainly wouldn't want to run any scripts on my machine if I knew that was possible on Linux, because merely being on the sudoers list would mean that my credentials are enough to damage my entire workstation. This doesn't even speak to the effect this would have if you got access to a sysadmin's account on a large network.
Consider for a moment all the tools and mechanisms in place to synchronize Active Directory passwords across domains, realms, and even 3rd party systems. Every one of those would completely break if you were to implement simple change such as the use of a salt.
That's why I've been saying for many years now that, "if you care about security do not use Windows." There's no mechanism available to actually make it secure because you can't change how it works internally. The best you can hope for is some obfuscation/hacks/tricks in regards to hardening (e.g. rename Administrator account, use entirely different credentials for administrative tasks, disable zillions of insecure defaults, etc). Then just hope you're never targeted.
If just one workstation is compromised an attacker can elevate their privileges to that of Domain Administrator with a few simple steps:
1. Install keylogger or password-dumping tool. 2. Force workstation to unjoin from the domain or cause some other problem that requires a Domain Admin to login to correct the issue. 3. Use credentials of Domain Admin to access a Domain Controller. 4. Dump the entire password database of Active Directory. 5. Crack the password database using some GPU instances in minutes.
After step #2 the attacker basically "owns" your network and can do whatever they want. You can mitigate it by joining Windows workstations using credentials that only have the power to perform a join but this is usually just a minor setback for an attacker as there's a plethora of tools and tricks they can take advantage of to escalate to Domain Admin.
For more information on how easy all this is: http://pentestmonkey.net/uncategorized/from-local-admin-to-d...
* The attacker can immediately view the user's password or just look at the saltless hashes (if they want).
Now let's compare that to, say, a Linux desktop (where similar zero days are extremely rare):
* Attacker will have to install a keylogger (usually by messing with the user's .profile, .bash_profile, .bashrc, etc) and wait for the user to spawn a new shell process where they actually enter their password at some point. This could be a long, long time or never at all if the user doesn't use the shell much. * Alternative: Because the shell option is unreliable (especially with more distros/businesses disabling LD_PRELOAD by default) the attacker will usually just run a program/script that prompts the user for their password. Unsophisticated users will probably just enter it but most IT professionals (the ones with privileged access) would immediately have a "WTF?" moment and that's very risky to an attacker.
I'd also like to mention that with things like SELinux and Apparmor it is very difficult for a userspace process to mess with the memory of another userspace process even when they're running as the same user. This makes it much more tricky to escalate privileges or obtain a user's password on a Linux desktop than Windows. Then there's the fact that on Linux there's a plethora of tools to detect and stop things like fiddling with LD_PRELOAD in user profiles.
...and if you don't like how it works you can actually change it! The source code for the kernel, the shells, the desktops, etc is there for you to do with as you please.
Two fatal flaws in your assumption.
1) Linux desktops in enterprise settings are incredibly rare. Linux servers? Way more common, but I can't remember any large corporation or enterprise using Linux desktops - it just doesn't happen.
2) Zero-day exploits DO happen to Linux. Would you be surprised if I told you:
"Vulnerabilities in the Linux kernel fixed in 2012 went unpatched for more than two years on average, more than twice as long as it took to fix unpatched flaws in current Windows OSes, according security firm Trustwave.
Zero-day flaws — software vulnerabilities for which no patch is available — in the Linux kernel that were patched last year took an average of 857 days to be closed, Trustwave found. In comparison zero-day flaws in current Windows OSes patched last year were fixed in 375 days."
http://www.zdnet.com/linux-trailed-windows-in-patching-zero-...
>>>> .and if you don't like how it works you can actually change it! The source code for the kernel, the shells, the desktops, etc is there for you to do with as you please.
I actually surprised you made this point, considering its been shown multiple times where malware and rootkits have been introduced into various Linux kernels. Just because something is open source, doesn't mean everybody is going to take the time to examine the source code and make sure its clean.
From 2009: http://www.darkreading.com/vulnerability/attack-sneaks-rootk...
"The attack attack exploits an oft-forgotten function in Linux versions 2.4 and above in order to quietly insert a rootkit into the operating system kernel as a way to hide malware processes, hijack system calls, and open remote backdoors into the machine, for instance"
"But Linux experts point out that the technique Lineberry is demonstrating at Black Hat indeed been has been deployed before with the so-called SuckIT rootkit, and as far back as the late 1990s with direct kernel-object modification (DKOM) rootkits]."
I'm quite surprised that LSASS.EXE is not protected in the same manner as AUDIODG.EXE [2]. Just goes to show how DRM protection is considered more important than system security.
[1] http://philosecurity.org/pubs/davidoff-clearmem-linux.pdf
[2] http://msdn.microsoft.com/en-us/library/windows/hardware/gg4...
It's no wonder so many web developers use OS X or Linux.
They have excellent tools available for Windows developers. But step out of that silo and man, just forget it. You have to fight your own system every step of the way.
This is an example of a strategy tax (http://scripting.com/davenet/2001/04/30/strategyTax.html): Microsoft's strategy for a loooong time was to pretend like Windows was the only thing that existed. When Windows was a majority monoculture, this worked pretty well for them. But now that it's just one ecosystem among many, it forces their developer-tools people to pull their punches so as to avoid undercutting their Windows people.
What I don't understand is why Microsoft don't just include an ssh client in their software with some half decent key 'gui' key managing nik-naks. In that way your starting out web developer would not have any need to consider installing a linux distro.
Just by not having any linux friendly terminal they are inviting people to go dual boot which can end with them finding they don't need Windows or even Adobe as much as they thought they did. It makes as much sense as building the Berlin Wall.
Can you elaborate about what you mean with the pretty general term 'security'? Cause I've heard this before, and using both some linux distros and some windows versions I never felt particularly unsecure on any of them. Maybe that's a false feeling though - but how to check it? E.g. last time I checked, during normal operations, none of my boxes would have in- nor outbound connections to any peers that I didn't know of. And last time I ran a bunch of virus/malware scans on the windows boxes everything was fine as well. But if I understand you correctly your claim is this is not sufficient?
Now, how realistic a danger a HTTP MITM is it depends on your threat model; I don't think anyone's doing this on a large scale (other than governments in places like Iran and North Korea). But if you're worried about attackers targeting you specifically, then I think this is a valid threat vector.
MS tried to address this in earlier windows with digital signing of downloads (you get a warning if you try to run an unsigned executable, and a different warning identifying the publisher for a signed one, assuming the executable in question is marked as having been downloaded from the internet), and by integrating an app store into windows 8 (I think?). If done correctly, this would prevent this kind of attack - if you only ever run signed executables, and you trust the signers, you're safe. But the fact that even PuTTY, supposedly a piece of security software, is an unsigned download, suggests that this approach hasn't really spread through the windows software ecosystem yet. (The other approach that might work is extending UAC into some kind of full containerization approach, and isolating applications more fully from each other).
Now, a desktop system is always going to run a GUI, but a server has its attack surface reduced by not having a GUI, and most Windows servers have a GUI.
https://news.ycombinator.com/item?id=7338118
Also consider for a moment that everything is executable by default in Windows. Meaning, you download a binary from wherever, double-click on it, and it will execute.
Here's how that works on a Linux workstation: You download something, explicitly set the execute bit on the file, then you can double-click on it to execute (assuming it is statically compiled for the correct architecture).
The average user does not know or care how to set the execute bit on a downloaded file. This alone is a huge hurdle for attackers to overcome.
But then the other one remains, basically for any OS: if signature-based scanners aren't good enough, how do you properly check you are secure? Is something like connection logging sufficient?
The amount of hyperbole in this thread is amazing, but so far your comment represents the absolute peak of it.
I hope you're proud. It's quite an achievement.