Really? Wow, lame. I knew it was open source because it's been ported to Windows RT (requires jailbreak, of course), but taking it closed source is BS. Ah, well, the open version will live on anyhow.
No, you're right about the Surface Pro. It's an x64 (Core i5 to be specific) tablet which runs Windows 8[.1] Pro.
For Microsoft's *intended* use case (where you use the Store to get apps, simultaneously limiting your exposure to malware, having one place you can find the tools you need for your tasks, and giving MS a cut of every "purchase" [in quotes because DRM]), the Surface and Surface Pro do generally run the same applications. There are very few apps available (on the Store) for x86 but not for ARM, because generally speaking, it's either no effort at all (managed code) or a simple drop-down change in Visual Studio followed by a recompile.
VLC is the odd one out here, because it's native code but isn't compiled using Visual Studio (well, except for the UI). GCC can't target Windows RT yet, so at the moment they can't compile VLC for that platform.
"Metro" is (was?) a lot more than just being full-screen. There's integration with the task switcher, support for snapping windows side-by-side, support for notifications, and so on. Making all that stuff work on something that wasn't written from the ground up to be a "Windows Store app" is hard. Chrome does it, but Google has a lot more resources than Mozilla.
Some particular reason you chose to spend money instead of getting the free and open-source Classic Start Menu (from Classic Shell)? Seems kind of silly.
Anyhow, I happen to think you're an idiot if you can't use the same UI (and by far the most productive one) that's been present in Windows since Vista, namely "hit Start (or the Windows key), type a few letters of the program name, hit Enter". It's faster than any mouse-driven interaction and doesn't require manually finding anything in cascading menus *or* scrolling screens of tiles. But that's just, like, my opinion, man...
You are (very) mistaken. WinRT (Windows RunTime) is an API set, a platform for running what Microsoft has (at various times) called "Metro", "Modern", "Immersive", and "Windows Store" apps. While you can make a full-screen touch-friendly UI without using WinRT, you need to use WinRT to integrate with the other "app" stuff that Win8.x does (the new task switcher, the sandboxing, the snapping, the automatic suspension in the background, etc.). To be fair, Firefox probably wasn't really trying to do that (the sandbox part, in particular, would be Really Good for them to have but would be a lot of work) so I expect it was more like what Chrome is doing, where they tack some Win32 UI functions onto their otherwise-traditional browser.
Windows RT, on the other hand, is completely different from WinRT. It can run WinRT apps, but saying they're the same thing would be like saying that Linux and the JVM are the same thing. Well, aside from the fact that those are made by different companies and don't have idiotically similar names... To the best of my knowledge, there was no real effort to port Firefox to Windows RT. I've tried doing that port myself (as a desktop application for jailbroken RT systems, not as a "Metro"/WinRT app) and it would be a tremendous amount of work.
Let's see... Well, the obvious counterpoint to your argument is that PayPal *did* succeed. I happen to hate what it's become (all the abuses of banks, plus a few others, but even less regulation), but back when Musk was starting it up the idea was pretty revolutionary. Even further back, though, there's his startup Zip2, which was sold for over $340 million back in 99.
Since then, his *three* companies (people always forget SolarCity...) all seem to be doing fine. SpaceX has huge contracts, Tesla can't manufacture fast enough to keep up with demand, and SolarCity is one of the top installers of photovoltaic panels in the USA. Sure, they *could* fail, but so could IBM or Google or Coca-Cola. None of them are *likely* to, though. In fact, in the last decade Tesla is just about the only US-based car company that hasn't gone bankrupt...
As for whether the NJ law is aimed at Tesla, you'd have to be a worse nutjob than you claim Musk is to not see it. Let's see, a proposed bill that prohibits a car sales model which happens to be used by exactly one company in the world, right as that company is getting hugely successful? Yeah, there's no evidence at all that this is aimed squarely at Tesla... </SARCASM>
Some people think still using 12-year-old OSes is a good idea.
"And having used Apple's AutoEngineStarterCrank, it's one of the slickest ways to start your car. Sure, early Apple cars required you to turn the crank by hand, but these days you just get out, plug the AutoEngineStartCrank into the front of the car, and it does the work for you!"
As "no crapware", somebody hasn't looked very closely at the Apple drivers... Feature-crippled and riddled with security vulnerabilities compared to the standard ones that Apple often keeps just barely incompatible with their otherwise-standard hardware. Report the latter problem and Apple might fix it in the version of BootCamp for the next OS X release. Unless that's any time soon, in which case you'll have to wait for the version after that. In my more cynical moments, I figure it's because Apple has a vested interest in making Windows appear insecure, so long as it can't easily be traced back to their hardware or software being the problem.
"WinRT" != "Windows RT". This is even discussed in the linked article (yeah, yeah).
Microsoft's branding people should be lined up along a wall, beaten with baseball bats, shot, and then pitched out a fifth-story window onto rusted spikes. OK, maybe that's excessive. There's no need to waste the bullets.
WinRT is an API set, intended for use with "Windows Store apps" (a.k.a. "Metro" or "Modern" apps). It is intended to be sandbox-friendly (for example, having functions to let the user pick a file via a trusted, out-of-process component), battery-friendly (apps are notified when no longer in the foreground, and by default suspend themselves), touch-friendly (you can do the UI in a number of ways, but the standard ways use the "Metro" paradigm with big, swipe-able screens), and responsive (the default behavior is for anything which is likely to block for a while - such as accessing network resources - to be moved of the UI thread). WinRT is usable on x86, x64, and ARM. You can code for it in C++,.NET, or JavaScript.
Windows RT is an operating system, an edition of Windows 8 (or now of Windows 8.1) compiled for ARM processors. Aside from the target architecture and a feature set somewhere between the normal and Pro x86 editions (it includes some stuff like BitLocker that the normal edition didn't have at least in 8.0, but is otherwise not very Pro-ish), and the removal of a bunch of legacy compatibility stuff, it's very much a straightforward port. The main difference from a user's perspective is that in RT, Windows enforces signature validation on all binaries loaded outside of an app sandbox, preventing third-party "desktop" programs from running. RT 8.0 was "jailbroken" to remove this restriction; it's just a kernel-mode flag that if changed, reverts the OS to basically just another Win8 platform. Windows RT can run Windows Store apps just fine, so long as they're written in an architecture-independent language (JS, or anything on the.NET framework) or are compiled for the THUMB-2 instruction set that Microsoft uses on ARM.
VLC is being ported to Windows RT as we speak. The port to the WinRT platform means they just need to re-compile it for RT (ARM). Unfortunately, while this should be simple, VLC doesn't currently compile under MSVC and GCC doesn't know how to target Windows RT. The VLC team is tackling both of these problems; fixing either one will let them proceed with the port. (Personally, I hope they fix the latter one; there's a lot of open-source software we could port to jailbroken RT except that it only compiles under GCC and GCC doesn't know how to target Win32/THUMB-2 yet.)
Porting to RT (ARM) is ongoing. The problem is that GCC doesn't know how to target Win32-THUMB2, and VLC doesn't compile under MSVC yet. They're looking at solving both of those problems, and will go with whichever one bears fruit sooner.
Personally, I hope for the former. GCC being able to target RT would allow us (the users of jailbroken RT devices, which are basically low-power Windows laptop/tablet things with great battery life but you have to re-compile native apps) to port a bunch more open-source software. An awful lot of OSS only builds under GCC and its ilk, so while porting to RT is nominally very easy (in Visual Studio, it's mostly a matter of changing a drop-down in Platform Configuration), many of the apps we have source code to can't be ported without a lot of work.
It's worth noting that.NET apps don't need to be modified at all in most cases (even if they use P/Invoke, it works fine), and we have runtimes for Python, Java, Perl, Ruby, and more. It's just the native code that's a pain. Dynamic recompilation to x86 sort of works - there's even a tool that does it transparently when you try to run an x86 EXE - but it's slow as hell on ARM.
Oh, and one other reason to port it to RT: Once you've ported to WinRT (the API set used for Store/"Metro" apps) and to THUMB-2 (the instruction set Microsoft uses on ARM processors), you can port to WP8 as well. *That* would be a real boon; there are probably a lot more WP8 devices than Windows RT devices, and having VLC on them would be great.
Good to know, thanks! WP7 used MTPZ (Zune-extended/encrypted MTP) and was very Linux-unfriendly, but WP8 appears to use bog-standard MTP. I hadn't tried it on Linux yet but am not surprised that it's reported to work well.
There have been WP-exclusive games since launch. I believe Wordament was exclusive when it launched two years ago, and it's only just recently appeared on non-MS platforms. A number of Microsoft/Xbox-franchise titles (like Halo and Fable) have WP-exclusive games that are either parts of the overall series, or companions to specific games in it. I'm sure there are tons of others.
Windows Phone has TouchDevelop, which is essentially a scripting IDE that allows the developer to select objects by touch rather than needing to type everything out. You can develop apps with it, and even publish them on the store. It's created by Microsoft Research, and was first launched on WP7 something like three years ago. https://www.touchdevelop.com/
They aren't actually very light. Between the battery cells and the armor plate protecting them, the Model S weighs over two tons (4647 lb, or 2108 kilo). That said, the Beast weighs a few times as much, due to being armored on all sides (instead of just the underneath). With that said, they do save weight elsewhere when possible (aluminum for the body except the structural/safety parts, for example).
You *could* make an electric Beast, but it would have relatively short range hauling that much armor around.
This is why you should use unique email addresses for each account. Gmail kind of supports this (they ignore . characters, and anything after a + character, when figuring out the mailbox to send a message to). So you can, for example, use yourgmailaddress+slashdot@gmail.com to sign up for Slashdot (not that you, AC, would ever do such a thing) and use yourgmailaddress+bankname@gmail.com when signing up for online banking, and be secure against the attack you describe unless somebody really clever figures out your naming scheme.
There are other webmail providers that do an even better job of handling unique, disposable addresses.
Wow, you're trying (and I appreciate that) but you really need to think this through a lot harder!
1) Password "guessing" isn't done by a human who will get bored. It's automated, and *extremely* fast. Let's say I can submit 10 password attempts per second (practically speaking, even a shitty home connection can probably manage closer to 50; a botnet could manage tens of thousands easily if the login server is up to it). Just because your password isn't in the 10 most commonly used ones doesn't mean it isn't in the 600 most commonly used ones. Oh no, instead of one second, it took my automated proxy a full minute to break into your account! As if that's a meaningful delay for a targeted attack...
2) How the heck is the user going to "run out" of strong passwords? I mean, even if the site prohibits re-using the old password after a reset, there are a quite literally infinite number of possible passwords. I'll grant that if you kept this attack up until the heat death of the universe, it would eventually reach the point where my "password" might need to longer than a typical sentence in English, but whoop-de-do. You could keep this kind of attack up all year without running the user out of dictionary words, so long as they aren't logging in 20 times a day! You couldn't run somebody out of pairs of such words in a natural human lifetime. That's ignoring case, and using the stupidest possible password generation scheme (choose the next word [pair] from the dictionary). A decent password scheme would be vastly more secure.
3) This user notes that somebody is *constantly* trying to brute force their password. Let's say you've managed to keep it up for months without getting your IP blocked or getting arrested under the CFAA or some such thing. The target of the attack has run through dozens of passwords. Why the hell would they decide to use a really weak one (knowing there's a constant attack going on) for their next one? Wouldn't it make a lot more sense at that point to hammer on the keyboard for five seconds when asked to create their password, knowing full well they will need to reset it next time they want to log in anyhow, due to that asshole wasting their time forcing resets constantly?
Yeah, you *really* didn't think about that one very hard, did you?
Detecting weak passwords is trivial. Here's how you do it: take a password database (there have been lots of leaked passwords from various insecure sites). Sort it by how common the password is, descending order. Require that the user's new password not be in the upper portion (upper thousand or so would probably be a good start) of the list. Update that list periodically, to account for the possibility of password shift.
For bonus points, do the following: Hash every password in the list to make it marginally more difficult to reverse (for practical reasons, you can't use a strong password verification function like SCrypt or PBKDF2-with-lots-of-iterations here, but you shouldn't use plain text). Make sure the user's proposed password's hash isn't one of the commonly used ones. Then, once it's accepted (and protected much more strongly, with salt and so on), add it to the list (incrementing the count if already present) and re-sort. That way, if you block the 1000 most common passwords and a bunch of people start using the 1001st-most-common, that password will itself quickly become unusable for new accounts and password changes or resets.
That's not even vaguely related to what CloudCracker does, which suggests to me that you haven't a clue what you're talking about.
This suggestion is reinforced by the fact that you recommend adding a "feature" which will allow me to prevent you from logging into any website I want, for near-arbitrary values of "you". There are right ways to do anti-brute-forcing protections on a password. Time delays (on remotely accessible unauthenticated login pages) are almost never the right option.
Much better is to automatically initiate a password reset for the affected user, where practical. Where not-so-practical, require a high-quality CAPTCHA after more than, on, three failed attempts. The first approach makes brute-forcing practically impossible unless you have control over the password reset mechanism (in which case you would just have triggered that yourself, then completed the process on behalf of the victim). Worth noting here that the site needs to log the user in directly as part of the password reset (rather than just bouncing them back to the login page) since the attacker can force another reset almost instantly. The second approach slows down brute-forcing without making it too hard for the user, and makes *automated* brute-forcing nearly impossible.
TLC client cert?!? Really? Oh, PLEASE tell me what bank that is! If they're available in the US I would consider switching just to approve their use of that approach.
My bank (Wells Fargo) uses case-insensitive 8-character alphanumeric passwords. At least, the limit of 8 characters was present when I last tried to create a password. Maybe they're better now, but I kind of doubt it (the check is still case insensitive...)
Yes, yes, one in every 10^85 random passphrases with have the same SHA256 hash. OH NOES! Meanwhile, unhashed (or weakly hashed) passwords are trivial to reverse (and then use to log in as those users, or to try logging in as them on other sites as well) as soon as the password database gets dumped. Such dumps happen all the time. I would be willing to wager that in the entire history of the Internet, nobody has blindly (i.e. without knowing the hash they were trying to generate) stumbled onto a password verifier hash collision (i.e. not simply guessing the user's actual password, but trying a different one and having it accepted anyhow) if a cryptographically secure hash was used (hell, I'll even allow the use of the broken and deprecated MD5).
"strictly speaking storing hashes is less secure" my ASS. You are full of bullshit, oh random AC.
Yeah... T-Mobile actually said in their last earnings call that they now get less money per subscriber than before. So at least for TMo customers, prices are definitely going down...
Admin approval is not actually required. At least on Windows, each user account has its own personal certificate store, which that user can install to just fine.
Additionally, browsers like Firefox (which store their certs separately from the OS) can (and often are) installed in such a way that the cert store is in a user-writable location. That's obviously possible for a user to edit.
Tom *EXPLICITLY* pointed out the need to compromise one of the machines with the private key on it. That probably means whatever firewall/proxy boxes are doing the interception, since by necessity they will have the private key (and don't pretend it is actually possible to make one of those non-exportable, short of a dedicated hardware module.
But sure, go on a half-page rant about stuff that has nothing to do with what he said. After all, clearly *he* is the one who "utterly fail[s] to understand", right?
On 64-bit, at least, a driver needs to be signed with a cert that chains to Microsoft if you want to avoid the warnings. Well, unless you're in testsigning mode, but that's literally just turning off security features so nobody is going to do it regularly.
Slashdot Mirror
Really? Wow, lame. I knew it was open source because it's been ported to Windows RT (requires jailbreak, of course), but taking it closed source is BS. Ah, well, the open version will live on anyhow.
No, you're right about the Surface Pro. It's an x64 (Core i5 to be specific) tablet which runs Windows 8[.1] Pro.
For Microsoft's *intended* use case (where you use the Store to get apps, simultaneously limiting your exposure to malware, having one place you can find the tools you need for your tasks, and giving MS a cut of every "purchase" [in quotes because DRM]), the Surface and Surface Pro do generally run the same applications. There are very few apps available (on the Store) for x86 but not for ARM, because generally speaking, it's either no effort at all (managed code) or a simple drop-down change in Visual Studio followed by a recompile.
VLC is the odd one out here, because it's native code but isn't compiled using Visual Studio (well, except for the UI). GCC can't target Windows RT yet, so at the moment they can't compile VLC for that platform.
"Metro" is (was?) a lot more than just being full-screen. There's integration with the task switcher, support for snapping windows side-by-side, support for notifications, and so on. Making all that stuff work on something that wasn't written from the ground up to be a "Windows Store app" is hard. Chrome does it, but Google has a lot more resources than Mozilla.
Some particular reason you chose to spend money instead of getting the free and open-source Classic Start Menu (from Classic Shell)? Seems kind of silly.
Anyhow, I happen to think you're an idiot if you can't use the same UI (and by far the most productive one) that's been present in Windows since Vista, namely "hit Start (or the Windows key), type a few letters of the program name, hit Enter". It's faster than any mouse-driven interaction and doesn't require manually finding anything in cascading menus *or* scrolling screens of tiles. But that's just, like, my opinion, man...
You are (very) mistaken. WinRT (Windows RunTime) is an API set, a platform for running what Microsoft has (at various times) called "Metro", "Modern", "Immersive", and "Windows Store" apps. While you can make a full-screen touch-friendly UI without using WinRT, you need to use WinRT to integrate with the other "app" stuff that Win8.x does (the new task switcher, the sandboxing, the snapping, the automatic suspension in the background, etc.). To be fair, Firefox probably wasn't really trying to do that (the sandbox part, in particular, would be Really Good for them to have but would be a lot of work) so I expect it was more like what Chrome is doing, where they tack some Win32 UI functions onto their otherwise-traditional browser.
Windows RT, on the other hand, is completely different from WinRT. It can run WinRT apps, but saying they're the same thing would be like saying that Linux and the JVM are the same thing. Well, aside from the fact that those are made by different companies and don't have idiotically similar names... To the best of my knowledge, there was no real effort to port Firefox to Windows RT. I've tried doing that port myself (as a desktop application for jailbroken RT systems, not as a "Metro"/WinRT app) and it would be a tremendous amount of work.
LOL!
Let's see... Well, the obvious counterpoint to your argument is that PayPal *did* succeed. I happen to hate what it's become (all the abuses of banks, plus a few others, but even less regulation), but back when Musk was starting it up the idea was pretty revolutionary. Even further back, though, there's his startup Zip2, which was sold for over $340 million back in 99.
Since then, his *three* companies (people always forget SolarCity...) all seem to be doing fine. SpaceX has huge contracts, Tesla can't manufacture fast enough to keep up with demand, and SolarCity is one of the top installers of photovoltaic panels in the USA. Sure, they *could* fail, but so could IBM or Google or Coca-Cola. None of them are *likely* to, though. In fact, in the last decade Tesla is just about the only US-based car company that hasn't gone bankrupt...
As for whether the NJ law is aimed at Tesla, you'd have to be a worse nutjob than you claim Musk is to not see it. Let's see, a proposed bill that prohibits a car sales model which happens to be used by exactly one company in the world, right as that company is getting hugely successful? Yeah, there's no evidence at all that this is aimed squarely at Tesla... </SARCASM>
Some people think still using 12-year-old OSes is a good idea.
"And having used Apple's AutoEngineStarterCrank, it's one of the slickest ways to start your car. Sure, early Apple cars required you to turn the crank by hand, but these days you just get out, plug the AutoEngineStartCrank into the front of the car, and it does the work for you!"
As "no crapware", somebody hasn't looked very closely at the Apple drivers... Feature-crippled and riddled with security vulnerabilities compared to the standard ones that Apple often keeps just barely incompatible with their otherwise-standard hardware. Report the latter problem and Apple might fix it in the version of BootCamp for the next OS X release. Unless that's any time soon, in which case you'll have to wait for the version after that. In my more cynical moments, I figure it's because Apple has a vested interest in making Windows appear insecure, so long as it can't easily be traced back to their hardware or software being the problem.
Seriously crappy drivers, mind you (I've found trivial EoP-to-kernel-from standard-user bugs in them), but at least they exist...
The "Metro" version is also free. The non-free apps are scams.
"WinRT" != "Windows RT". This is even discussed in the linked article (yeah, yeah).
Microsoft's branding people should be lined up along a wall, beaten with baseball bats, shot, and then pitched out a fifth-story window onto rusted spikes. OK, maybe that's excessive. There's no need to waste the bullets.
WinRT is an API set, intended for use with "Windows Store apps" (a.k.a. "Metro" or "Modern" apps). It is intended to be sandbox-friendly (for example, having functions to let the user pick a file via a trusted, out-of-process component), battery-friendly (apps are notified when no longer in the foreground, and by default suspend themselves), touch-friendly (you can do the UI in a number of ways, but the standard ways use the "Metro" paradigm with big, swipe-able screens), and responsive (the default behavior is for anything which is likely to block for a while - such as accessing network resources - to be moved of the UI thread). WinRT is usable on x86, x64, and ARM. You can code for it in C++, .NET, or JavaScript.
Windows RT is an operating system, an edition of Windows 8 (or now of Windows 8.1) compiled for ARM processors. Aside from the target architecture and a feature set somewhere between the normal and Pro x86 editions (it includes some stuff like BitLocker that the normal edition didn't have at least in 8.0, but is otherwise not very Pro-ish), and the removal of a bunch of legacy compatibility stuff, it's very much a straightforward port. The main difference from a user's perspective is that in RT, Windows enforces signature validation on all binaries loaded outside of an app sandbox, preventing third-party "desktop" programs from running. RT 8.0 was "jailbroken" to remove this restriction; it's just a kernel-mode flag that if changed, reverts the OS to basically just another Win8 platform. Windows RT can run Windows Store apps just fine, so long as they're written in an architecture-independent language (JS, or anything on the .NET framework) or are compiled for the THUMB-2 instruction set that Microsoft uses on ARM.
VLC is being ported to Windows RT as we speak. The port to the WinRT platform means they just need to re-compile it for RT (ARM). Unfortunately, while this should be simple, VLC doesn't currently compile under MSVC and GCC doesn't know how to target Windows RT. The VLC team is tackling both of these problems; fixing either one will let them proceed with the port. (Personally, I hope they fix the latter one; there's a lot of open-source software we could port to jailbroken RT except that it only compiles under GCC and GCC doesn't know how to target Win32/THUMB-2 yet.)
Porting to RT (ARM) is ongoing. The problem is that GCC doesn't know how to target Win32-THUMB2, and VLC doesn't compile under MSVC yet. They're looking at solving both of those problems, and will go with whichever one bears fruit sooner.
Personally, I hope for the former. GCC being able to target RT would allow us (the users of jailbroken RT devices, which are basically low-power Windows laptop/tablet things with great battery life but you have to re-compile native apps) to port a bunch more open-source software. An awful lot of OSS only builds under GCC and its ilk, so while porting to RT is nominally very easy (in Visual Studio, it's mostly a matter of changing a drop-down in Platform Configuration), many of the apps we have source code to can't be ported without a lot of work.
It's worth noting that .NET apps don't need to be modified at all in most cases (even if they use P/Invoke, it works fine), and we have runtimes for Python, Java, Perl, Ruby, and more. It's just the native code that's a pain. Dynamic recompilation to x86 sort of works - there's even a tool that does it transparently when you try to run an x86 EXE - but it's slow as hell on ARM.
Oh, and one other reason to port it to RT: Once you've ported to WinRT (the API set used for Store/"Metro" apps) and to THUMB-2 (the instruction set Microsoft uses on ARM processors), you can port to WP8 as well. *That* would be a real boon; there are probably a lot more WP8 devices than Windows RT devices, and having VLC on them would be great.
Good to know, thanks! WP7 used MTPZ (Zune-extended/encrypted MTP) and was very Linux-unfriendly, but WP8 appears to use bog-standard MTP. I hadn't tried it on Linux yet but am not surprised that it's reported to work well.
There have been WP-exclusive games since launch. I believe Wordament was exclusive when it launched two years ago, and it's only just recently appeared on non-MS platforms. A number of Microsoft/Xbox-franchise titles (like Halo and Fable) have WP-exclusive games that are either parts of the overall series, or companions to specific games in it. I'm sure there are tons of others.
Windows Phone has TouchDevelop, which is essentially a scripting IDE that allows the developer to select objects by touch rather than needing to type everything out. You can develop apps with it, and even publish them on the store. It's created by Microsoft Research, and was first launched on WP7 something like three years ago. https://www.touchdevelop.com/
They aren't actually very light. Between the battery cells and the armor plate protecting them, the Model S weighs over two tons (4647 lb, or 2108 kilo). That said, the Beast weighs a few times as much, due to being armored on all sides (instead of just the underneath). With that said, they do save weight elsewhere when possible (aluminum for the body except the structural/safety parts, for example).
You *could* make an electric Beast, but it would have relatively short range hauling that much armor around.
This is why you should use unique email addresses for each account. Gmail kind of supports this (they ignore . characters, and anything after a + character, when figuring out the mailbox to send a message to). So you can, for example, use yourgmailaddress+slashdot@gmail.com to sign up for Slashdot (not that you, AC, would ever do such a thing) and use yourgmailaddress+bankname@gmail.com when signing up for online banking, and be secure against the attack you describe unless somebody really clever figures out your naming scheme.
There are other webmail providers that do an even better job of handling unique, disposable addresses.
Wow, you're trying (and I appreciate that) but you really need to think this through a lot harder!
1) Password "guessing" isn't done by a human who will get bored. It's automated, and *extremely* fast. Let's say I can submit 10 password attempts per second (practically speaking, even a shitty home connection can probably manage closer to 50; a botnet could manage tens of thousands easily if the login server is up to it). Just because your password isn't in the 10 most commonly used ones doesn't mean it isn't in the 600 most commonly used ones. Oh no, instead of one second, it took my automated proxy a full minute to break into your account! As if that's a meaningful delay for a targeted attack...
2) How the heck is the user going to "run out" of strong passwords? I mean, even if the site prohibits re-using the old password after a reset, there are a quite literally infinite number of possible passwords. I'll grant that if you kept this attack up until the heat death of the universe, it would eventually reach the point where my "password" might need to longer than a typical sentence in English, but whoop-de-do. You could keep this kind of attack up all year without running the user out of dictionary words, so long as they aren't logging in 20 times a day! You couldn't run somebody out of pairs of such words in a natural human lifetime. That's ignoring case, and using the stupidest possible password generation scheme (choose the next word [pair] from the dictionary). A decent password scheme would be vastly more secure.
3) This user notes that somebody is *constantly* trying to brute force their password. Let's say you've managed to keep it up for months without getting your IP blocked or getting arrested under the CFAA or some such thing. The target of the attack has run through dozens of passwords. Why the hell would they decide to use a really weak one (knowing there's a constant attack going on) for their next one? Wouldn't it make a lot more sense at that point to hammer on the keyboard for five seconds when asked to create their password, knowing full well they will need to reset it next time they want to log in anyhow, due to that asshole wasting their time forcing resets constantly?
Yeah, you *really* didn't think about that one very hard, did you?
Detecting weak passwords is trivial. Here's how you do it: take a password database (there have been lots of leaked passwords from various insecure sites). Sort it by how common the password is, descending order. Require that the user's new password not be in the upper portion (upper thousand or so would probably be a good start) of the list. Update that list periodically, to account for the possibility of password shift.
For bonus points, do the following:
Hash every password in the list to make it marginally more difficult to reverse (for practical reasons, you can't use a strong password verification function like SCrypt or PBKDF2-with-lots-of-iterations here, but you shouldn't use plain text). Make sure the user's proposed password's hash isn't one of the commonly used ones. Then, once it's accepted (and protected much more strongly, with salt and so on), add it to the list (incrementing the count if already present) and re-sort. That way, if you block the 1000 most common passwords and a bunch of people start using the 1001st-most-common, that password will itself quickly become unusable for new accounts and password changes or resets.
That's not even vaguely related to what CloudCracker does, which suggests to me that you haven't a clue what you're talking about.
This suggestion is reinforced by the fact that you recommend adding a "feature" which will allow me to prevent you from logging into any website I want, for near-arbitrary values of "you". There are right ways to do anti-brute-forcing protections on a password. Time delays (on remotely accessible unauthenticated login pages) are almost never the right option.
Much better is to automatically initiate a password reset for the affected user, where practical. Where not-so-practical, require a high-quality CAPTCHA after more than, on, three failed attempts. The first approach makes brute-forcing practically impossible unless you have control over the password reset mechanism (in which case you would just have triggered that yourself, then completed the process on behalf of the victim). Worth noting here that the site needs to log the user in directly as part of the password reset (rather than just bouncing them back to the login page) since the attacker can force another reset almost instantly. The second approach slows down brute-forcing without making it too hard for the user, and makes *automated* brute-forcing nearly impossible.
TLC client cert?!? Really? Oh, PLEASE tell me what bank that is! If they're available in the US I would consider switching just to approve their use of that approach.
My bank (Wells Fargo) uses case-insensitive 8-character alphanumeric passwords. At least, the limit of 8 characters was present when I last tried to create a password. Maybe they're better now, but I kind of doubt it (the check is still case insensitive...)
Morons. We trust these people with our money?
Yes, yes, one in every 10^85 random passphrases with have the same SHA256 hash. OH NOES! Meanwhile, unhashed (or weakly hashed) passwords are trivial to reverse (and then use to log in as those users, or to try logging in as them on other sites as well) as soon as the password database gets dumped. Such dumps happen all the time. I would be willing to wager that in the entire history of the Internet, nobody has blindly (i.e. without knowing the hash they were trying to generate) stumbled onto a password verifier hash collision (i.e. not simply guessing the user's actual password, but trying a different one and having it accepted anyhow) if a cryptographically secure hash was used (hell, I'll even allow the use of the broken and deprecated MD5).
"strictly speaking storing hashes is less secure" my ASS. You are full of bullshit, oh random AC.
Uh... you do know you can set multiple DNS servers, right? The OS will try them, in the order listed, until it gets a match or exhausts the list.
Yeah... T-Mobile actually said in their last earnings call that they now get less money per subscriber than before. So at least for TMo customers, prices are definitely going down...
Admin approval is not actually required. At least on Windows, each user account has its own personal certificate store, which that user can install to just fine.
Additionally, browsers like Firefox (which store their certs separately from the OS) can (and often are) installed in such a way that the cert store is in a user-writable location. That's obviously possible for a user to edit.
Yeah, you're stupid.
Tom *EXPLICITLY* pointed out the need to compromise one of the machines with the private key on it. That probably means whatever firewall/proxy boxes are doing the interception, since by necessity they will have the private key (and don't pretend it is actually possible to make one of those non-exportable, short of a dedicated hardware module.
But sure, go on a half-page rant about stuff that has nothing to do with what he said. After all, clearly *he* is the one who "utterly fail[s] to understand", right?
Moron
On 64-bit, at least, a driver needs to be signed with a cert that chains to Microsoft if you want to avoid the warnings. Well, unless you're in testsigning mode, but that's literally just turning off security features so nobody is going to do it regularly.