Forgot your password?

Comment: Re:hum (Score 2) 114

by TemporalBeing (#48205253) Attached to: Windows 0-Day Exploited In Ongoing Attacks

The problem is MS never had a small tutorial during windows installation or during the first boot showing users how to create a Standard User account and have an administrative account for elevating your rights for doing administrative stuff. But now, with windows 8 during the install, you can create any type account you like, but again, no tutorial.

The problem is one of history for Windows.

Windows was originally a place where every user was an Administrator. This encouraged developers to not pay attention to APIs used, so then applications came to be reliant on running only under users that were Administrators. Even Microsoft Office did that for a long time.

Then Microsoft split users up and now there was a special Administrator account and group. Except users wanted to continue using all the software they had from before that split. The solution? Make all users administrators. Developers kept designing software that required administrative access - even Microsoft Office.

Then came Windows Vista and UAC. Microsoft Office got fixed up; but many developers did not listen to years of warning. So then UAC started prompting the hell out of everyone. Windows 7 came along and most developers had fixed their software so UAC could be scaled back in its prompting some (really, that's the only difference between Win7 and Vista - the default threshold setting for UAC - in this matter).

Of course no where along the road did Microsoft make it easy to switch between users. Sure, there's "Run As..." but it's (a) not well known, (b) a PITA to use, and (c) doesn't solve every use case. UAC doesn't quite either. In neither case do either work like the priviledge escalation in Linux/Unix with "su" and "sudo" and their graphical equivalents. So everyone still must have the administrative access to do certain tasks.

And of course people are still trained that their user needs to be the Admin user for the system.

So there's still work to be done on Windows to bring a real "su"/"sudo" experience to Windows; but overall it's still very much a user issue since they're all trained to and expect that their Windows user will have admin rights whether they really need them or not.

Comment: Re:Damn linux (Score 1) 114

by TemporalBeing (#48205179) Attached to: Windows 0-Day Exploited In Ongoing Attacks

It's mildly funny that Server 2003 doesn't have this bug, and also was the last Windows Server that still used some Unix/BSD code.

(No, I'm not claiming a causal relationship...)

Which makes me think that WinXP was also not affected as it was closely related to Windows Server 2003. However, it's no longer supported so...

Comment: Re:Why the cloak and dagger? (Score 1) 154

by TemporalBeing (#48205105) Attached to: Ask Slashdot: Aging and Orphan Open Source Projects?

The company is not interested in supporting the software. So if their software is in peril, it is entirely in their hands.

This situation doesn't sound unusual to me. The company originally developed it because it addressed a need/demand at the time. The developers involved took a personal interest in it. The original need has long gone, but the developers have kept it going as a personal project that the company indulges.

But once the original developers leave, the company has no reason to continue their involvement with it. The people using it are not their customers (or are insignificant enough to be customers of no value). They owe it nothing, and suffer no "embarrassment" from walking way from it.

That being said, I don't know why the poster hasn't come out and said what the software is. It may answer a number of questions.

It could be that they haven't announced anything yet, so it could cause "material harm" to the company or put the TFA's author in a bad position in the company to announce something prior to any official annoucement. There are numerous legal reasons to not necessarily name a project; however much the community here may want them to do so.

Comment: Re:Slashdot Effect (Score 1) 120

by TemporalBeing (#48203361) Attached to: Overwhelmed By Recall For Deadly Airbags

Why? You'd have the gov't spend money to overbuild or be able to scale a website for the one time every few years it gets overloaded? Seems like a waste of money to me. It does just fine 99.9999999% of the time.

The other issue was that all the news articles said things like, "X Million Hondas Recalled!" As a Honda Accord owner, I clicked on the article and looked, only to discover it was for rather old Accords (nothing newer than like 2003; ours is a 2012). Others probably went to instead, only to find it didn't apply. (That headline should have been in the favorite clickbait poll. "X Million Cars from 1998-2003 recalled!" would have been better, but...fewer clicks!)

Recall applied to many more than just Hondas, and many different model years even outside the 1998-2003 years you quoted. So sure, car's model may not have had an issue, but many others did.

Also, forwarded to the other site so that didn't really make a difference.

Finally, I would expect any organization that has a mission like that of the site in question to be prepared should a major issue like this happen, primarily because it could happen at any time and they are the central source of information. The fact that it is a government website only makes it more important to be able to scale.

Your argument is like saying that the IRS website need not scale b/c it works just fine for 350 days of the year; it's only less than 15 days of the year that it sees major amounts of traffic. Sorry - but that doesn't work and safety should have a higher burden of reliance than the IRS.

Comment: Re:Recognition (Score 1) 150

by TemporalBeing (#48196697) Attached to: 'Microsoft Lumia' Will Replace the Nokia Brand

Then they were fools. The whole point of buying an established company is to buy the brand as well as the factories. Anyone can build a factory, usually for no more than it would cost to buy someone else out.

Except they weren't trying to buy the "brand". They were trying to buy the product to ensure that there was an actual product in the market with their failing OS on it; they were simply trying to buy market share; nothing more.

The fact that it's their name on it now won't change anything. It will still fail just as a badly as before (may be even worse).

Comment: Re:I don't buy it (Score 1) 265

by TemporalBeing (#48152873) Attached to: Confidence Shaken In Open Source Security Idealism

And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited

Can you please cite the policy? A quick glance through the Microsoft Security Bulletins reveals that most of them have not been actively exploited before being patched.

Of course you could argue that Microsoft is lying, but many security researchers do (privately) report vulnerabilities to Microsoft, and you really don't think some of them will publicize the bugs if they aren't fixed in, like, a year?

Or are you actually trying to say they don't fix them unless they have been reported, which is an entirely different thing?

Microsoft does not publicize all vulnerabilities reported to them; and not every reporter will publicize it either. So how many they actually know about is unknown. This is reported by most people that are writing about the issue, especially those comparing Microsoft's practices to Open Source's and comparing the numbers for the CVE reports between the groups.

Comment: Re:I don't buy it (Score 3, Insightful) 265

by TemporalBeing (#48146971) Attached to: Confidence Shaken In Open Source Security Idealism

I didn't say MS was better, I said the bash response was poor, and the poster I replied to couldn't possibly have had fixes in place within minutes as claimed.

I'm just pointing out that however poor the Bash devs response was, Microsoft's would have been worse.

Oh, and in your argument "up to 30 days" suddenly becomes "taken 30 days" - actually if bugs come in uniformly distributed in the 30 day cycle then average would be 15 days, or lower since sometimes they do go out-of-band.

Actually, my comment regarding "taken 30 days" for Microsoft is well founded in their historical turn-around for CVEs that they have acknowledged as being fixed. With a rare exception, they don't deliver any patches in under 30 days; and even 30 days is being gracious as it's usually more like 6 months so I'm already putting them on their own expedited schedule for such fixes.

Again, pointing out that however poor the Bash devs response was, Microsoft's at it best is worse.

Plus, the second (and third and fourth and so on) patches are only needed if the first (and second and third.,.) one is inadequate and not properly tested.

If the numerous people reviewing Bash, from multiple companies, and disciplines didn't find the issue with the first patch, then how would Microsoft with a far more limited set of people looking at the code be able to get the same kind of patch correct the first time and get all the corner cases figured out and fixed before releasing the first patch?

I'm not saying the Bash devs had 1 million eyes on this; but they certainly had a few hundred if not a thousand or so in total. Microsoft's equivalent group probably is no greater than 50 devs at best, likely smaller; and probably no where near the cross-discipinary skill set match either.

So if the Bash guys had to do a second patch (or even a third, etc) to fix it; chances are Microsoft would have had to have at least as many patches too.

Maybe MS are just as bad at that too, but the developers of Bash were certainly not good at it.

Agreed - kinda. The main point of the origin of this thread (article?) was that F/LOSS software could not deal as well as proprietary software; that somehow the proprietary vendors could do better with these kinds of bugs - both catching them and responding to them.

My point, is that based on its history - documented in numerous articles over the years - Microsoft is a prime example of showing that's not the case. That proprietary vendor's own policies and procedures prevent them from delivering anywhere near as good a turn around.

But here's the kicker - there is a similar exploit for cmd.exe. It's yet to be patched. ;-)
here's an example:
(And yes, I've seen it from other sources, just don't have those links right now.)

Comment: Re:Why? (Score 1) 986

What should really happen is Mr. Rossi should patent his device, and then anyone who wants to can read the patent and build their own replica, if they wish to do so. (Of course to sell their replica they would need to license the design from Mr. Rossi, since it would be patented)

Perpetual Motion Machines (and Cold Fusion) require a working device to receive a patent. There have been so many hoaxes that the US PTO (at least) wants a physical machine they can inspect in order to issue the patent.

Comment: Re:I don't buy it (Score 3, Interesting) 265

by TemporalBeing (#48144811) Attached to: Confidence Shaken In Open Source Security Idealism

How did you fix them in minutes when it took several days for correct patches to come out, for entirely predictable reasons (laughable approach of trying to find and fix all bugs at once in a parser never designed to be secure, when the real issue is that it should never be being fed untrusted input) ?

To my mind, that is the biggest failure of open source / free software in this case - 20+ yr old bug / insecure-feature in an obscure corner of a system never designed for today's threat environment - forgiveable - responsible disclosure, working with maintainers under embargo - good - publication along with a patch that was broken again within hours if not minutes - fail - everyone and his dog then panic-issuing further patches for one parser vulnerability after another before eventually someone (actually more than one different approach) fixes it properly the way it should have been done in the first place - spectacular fail

And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited; when an unknown exploit is exploited they take up to 30 days to release, and that still may not have everything fixed. So to put this in context, if Microsoft were the developers of Bash:

  • They would have sat on the bug for 20 years too if there were no known active exploits of it.
  • The first patch would have taken 30 days, not under 2 weeks (I don't know the real number, but it wasn't very long; and certainly under 2 weeks if not under 1 week).
  • The second patch would have still been needed, but would have taken yet another 30 days
  • Only a few developers would have had access to be able to review and fix anything

Too Much Privacy: Finnish Police Want Big Euro Notes Taken Out of Circulation 314

Posted by timothy
from the convenience-of-the-state dept.
jones_supa writes The Finnish Police are concerned that larger banknotes, namely the €200 and €500 banknotes, encourage criminal activity and should therefore be removed from Finnish cash circulation. Markku Ranta-aho, head of the Money Laundering Clearing House of Finland, says criminals prefer cash because it is harder for police to track. In contrast, a record of electronic money transfers remains in the banking system, which makes the police's job considerably easier. Ranta-aho also says citizens rarely use the larger banknotes anyway, with which The Bank of Finland's advisor Kari Takala agrees. However, The Bank of Finland is skeptical about the ability of a ban on €500 banknotes to eliminate underground labor and trade in Finland. Takala suggests criminals would just switch to smaller bills. More illegal transactions take place via bank transfers, he says.

Comment: Only addresses one side of the equation... (Score 1) 549

by TemporalBeing (#48136429) Attached to: Password Security: Why the Horse Battery Staple Is Not Correct
Password security is only partially maintained through what the user does.

If you care about password security you also have to think about the server-side. And there we are doing things that are also just as bad as passwords are often stored using a single encryption algorithm if they are encrypted at all; and often that algorithm is a simple MD5 or SHA1 hash of the password.

In addressing the server-side, we must also make things more variable by introducing settings that the server administrators set. The password is split according to the rules with each part passed through different algorithms, and the results merged using rules as well. One part of the password might pass through scrrypt, while another may pass through SHA512, and only portions used to get what is stored on disk.

Take care of the luxuries and the necessities will take care of themselves. -- Lazarus Long