I think their policy is typically to update to the latest model if the order hasn't shipped yet.
The same thing happened to be when I ordered a MacBook back in 2007, where a few days later they announced better specs and I got a notification saying they updated my order to reflect the changes.
It's one of the reasons my next laptop will probably still be Apple.
I think the percentage is interesting, but it adds nothing for either side of the debate (either for or against). I'm not challenging you, I'm talking about the people going back to that number in the thread you posted.
* I don't even know how to setup a master password and have never heard of the option being available in FF or Chrome. I also don't know what it does. Does it replace all password boxes with a master-password that you enter which then pulls down the appropriate password? Is it a keychain?
Saying "X people don't use this feature" could mean anything. It could mean the feature is buried in the system, or that the feature isn't descriptive enough, or that the feature is hard to understand... it doesn't default to being "people clearly don't want that feature".
[*] I could research it, but I'm giving you my current uneducated opinion to make a point.
Users can navigate menus. But given the out-of-the-way location of the "Use a master password" checkbox, what percentage of Firefox's users even know of it's existence? It's likely pretty low.
This is a failure of the browser manufacturers, not the users. I had no idea this was even possible until now- they should surface a feature like this a lot more clearly if they want people to use it.
There is a middle-ground. Something like MS Office's 'Ribbon UI' where they set out to minimize the interface while exposing features that were usually hidden deeply enough that users couldn't find them.
But if there is already malware on the user system, it just needs to wait until the user authenticates once in Firefox to get the master password, then it can fetch all the other passwords. Right?
Absolutely it could. However, the layer of defense provided by a master password is still (so far, seemingly) better than the instantaneous and automatic access to credentials malware could have when extracting credentials from Chrome and IE.
But yes, to answer your question (and to validate the other poster on this thread) - If malware infects your system, you will likely have a bad time.
I think you're answering in good faith but I find that caveat so overwhelming that it makes the point meaningless: if malware runs locally outside of a sandbox, you're screwed – full stop, end of story.
There are scenarios where master passwords are extremely useful and that's passive file disclosure such as a network home directory, a compromise of another account while you're not logged in, or – particularly relevant these days – a breached cloud sync service. I would make the case for that reason rather than as a malware resistance measure.
The long term fix requires architectural changes: none of the attacks described work directly on Mac OS X because the Keychain decoding happens in the securityd process which runs as root so the malware would trigger a confirmation prompt for each password it tried to pilfer. Unfortunately, this is also less than perfect as most users check the “Always allow” box granting permission to their browser for unprompted access…
Before everyone gets their pitchforks out, why don't we look at the URL and see that it has the "sample-" in it? Meaning that this is an example of words that can be filtered. It IS NOT a list of words Disqus automatically filters.
There is a filter tab in the Disqus admin area, one of those tabs is "filter," here is the text around below the restricted words input box:
"Separate words with commas. You may use .* (dot asterisk) as wildcard, but be careful not to be too aggressive. For example, s.*ck will match suck, but also sock and stack. Words must be at least 3 characters in length.
Wouldn't the URL be in their web server logs? Since the URL only last for an hour it would be a small window (plus their web server was hacked), but you could access other user accounts that way.
Usually username and password are sent via POST not GET so the logs don't have that data (unless you're IEEE and user GET and have your logs available through FTP).
The URL is only valid once, the web server can easily be configured to not log URLs on that subdomain/virtualhost, and if an attacker can read your web server logs you have probably other things you should be more concerned about.
Hmmm, it looks like you might be right. I tried it earlier with one in a private window and it worked twice, but when I just tried again it was invalid/expired (though the email is 50 minutes old).
And I certainly agree that if the server is compromised you've got more problems, but in the IEEE example the server wasn't hacked they just made a mistake by making the logs available.
Edit: yup, I must have made a mistake (not closing private window or using non-private window) in my test.
"but in the IEEE example the server wasn't hacked they just made a mistake by making the logs available"
It seems a bit harsh to judge the strength of an authentication scheme on the metric of "How well does it stand up to a system administrator storing and serving publicly all in-use authentication credentials?"
Sure, this scheme makes errors like that possible, there's always some "assumed competence" about the people deploying the web-app. I'd strongly disagree with, for example, WordPress using this as a default installation option (since there's an assumption that many WordPress users don't understand these sorts of issues) - but for someone like Marco to choose to do this on some software he's written and will likely be the only person to deploy? I'd be happy with him choosing this and understanding the simple risks and the obvious ways to ameliorate them.
(Especially since the only party "hurt" by a failure in the auth scheme is him - worst case scenario seems to me to be that someone stealing a paying subscribers auth url gets to read articles for free - it's not like this is going to expose a potentially useable-elsewhere password or allow the attacker to incur any extra costs to the subscriber.)
> It seems a bit harsh to judge the strength of an authentication scheme on the metric of "How well does it stand up to a system administrator storing and serving publicly all in-use authentication credentials?"
Is it harsh? Would it be harsh to judge an authentication scheme that stores all passwords in plaintext? Server logs don't typically contain data that should be considered secret. IF this authentication scheme led to secret information being stored in a file that wasn't expected to be secure, that would be a major problem, wouldn't it?
This type of authentication hasn't stood up to a large amount of scrutiny, so it is important to think through some attack vectors that might be opened up. This was one I thought up, but it isn't an issue since the tokens are one-shot.
For the record, I like this authentication scheme but that doesn't mean it shouldn't be challenged.
"Is it harsh? Would it be harsh to judge an authentication scheme that stores all passwords in plaintext? Server logs don't typically contain data that should be considered secret."
You're right, but server logs are also not considered to be publicly available, and someone made that mistake in the IEEE example. Server logs can also be configured to store form post data, there's a "simple misconfiguration" that in concert with ther IEEE's error would defeat just about any common auth scheme (it'd even put TOTP 3 factor auth logins at risk for the minute the magic nuber is valid).
You're right - it _should_ be challeneged. But it seems petty clear that the risks associated with auth disclosure here are effectively zero and all borne by Marco not the paying subscriber who's credential is mis-used, and there's no possibility to leverage an exploit of an account here to gain further access elsewhere, even if Marco _did_ fuck up so badly to allow easy discovery of login credentials, this scheme is still entirely suitable for this application. But I don't want my bank to use it.
Oh yes, in this case there is almost no risks for the client but I'm assuming someone will make a django plugin/ruby client/whatever plug-and-play version of this which may not have the same low bar of getting subscriber content on a site where paying is opt-in only.
(I wouldn't mind my bank using this, it's better than what they have in place...)
Source: Former Chicago native that purchased Safeway branded food at Dominick's.