Tag: passwords

Why Bruce Schneier Having An Open Wi-Fi Network Is No Good Reason For You To

Bruce Schneier, cryptography king, keeps his home network open. And despite what Tim Lee wrote in support of the idea, please don’t listen.

The justification is that the risk of someone using your network for illegal means is very low, while the risk of you getting hacked at the local coffee shop is potentially higher. Hence, worry about your machine, not your home connection.

I say BLAH! This piss poor argument ignores two significant points:

1) There is little or no benefit to you from opening your network; and

2) It takes minimal effort to secure your network with a password.

The risks may be low, but meanwhile you have nothing to gain. Meanwhile, the effort necessary to provide that little extra layer of protection likely outweighs the cost of that single long tail incident – one that could potential cause you tons of legal hassles.

If you are hell bent on providing web access to home visitors, I’ll take for granted that you trust them. Give them the key, like I do. Or if you’re wearing a tinfoil hat as you hand them their coffee, ask them to allow you to type it in yourself.

UPDATE: Being open can cause hassles (unless you don’t consider having your computer confiscated by less than technology savvy law enforcement officers a hassle).

No steadfast rules for storing/sharing financial data and its offspring online

Living in a user-generated online society, who owns the data and how can it be used have been persistent questions. The debate continues, particularly as data stores grow with more complex (and more personal) information.

Fred Wilson’s Union Square Ventures has invested in a company called Wesabe, which like several others aims to sort through and make sense of your personal financial information. Financial data is probably the most sensitive of all with regard to online conveyance, and individual concern as to how that data is handled is an obvious barrier to acceptance of services like Wesabe. The company has answered the call in part by publishing a “Data Bill of Rights,” the purpose of which is to alleviate anxieties regarding housing personal financial information with them. Mr. Wilson caveats the “press” by stating it’s a good start, and calls out for additional opinion. Mine are as follows (with the disclaimer that said opinions are by no means steadfast rules, nor are they necessarily cost-effectively operationally feasible)…

The Q&A

Who owns the metadata you and others create about the transactions that come into the system?

In the world according to credit card processors and credit reporting agencies, they do, and despite your requests to block its use there is probably a lot of metadata being gathered that doesn’t fall within the two-point type guidelines your creditors periodically send you. They’re likely using it – and you should get used to it. But with regard to opt-in services such as Wesabe, I think there’s a happy median to be had. Clearly, these types of online services see value in said metadata, and allowing you to remove your viewable information shouldn’t necessarily be accompanied by complete removal of the offspring (particularly if the service was offered for free). I believe if personally identifiable and proprietary data elements (meaning data uploaded, imported, or otherwise entered by the user) are stripped away from the metadata, then the result (or what’s left, if anything) should be available to the service provider.

Is it better to let the service do the tagging or is it better to let the community to do the tagging of the transactions?

Both. The services themselves are the machine, and the community is the blood and guts. Algorithms versus psychy, or the two working in harmony and learning from each other. I believe there is a lot of value to be gained from allowing the machine to suggest helpful tag elements to the users, and I believe the users should be ready, willing and able to reciprocate.

Should the tags be shared and if so, when and with whom?

This should depend on the data elements or transactions being tagged and who is doing the tagging. If the machine “suggests” a tag for a personally identifiable element, then the end user should have the option to reject that metadata. But that doesn’t mean the service shouldn’t be allowed to use that metadata in conjunction with non-personally identifiable information to improve itself for the benefit of others in the community. By the same token, user generated tags should be sharable within the community while directly related to said user (or their data) only with their permission, but the “transaction” which resulted in that choice should be something the machine is allowed to learn from.

Where should your login and passwords be stored?

Probably a personal choice issue – there are a lot of folks working on various solutions which include third-party authentication, token exchange, etc., and there is not enough information to make a blanket judgment call on the matter either. I will likely never input my bank, securities, or credit related login information into a third party service, regardless of the level of security assurance the service provides. That is my choice, and the logic is this: a centralized repository of such data will attract threats in direct proportion to the service’s popularity, particularly given the potentially profitable nature of that data. My accounts are spread across numerous vendors, and while the possibility of having my data stolen through phishing attempts and the like increases with each transaction, I personally don’t engage in large numbers of them. I assume the risk is lesser than that presumed in a “large target” stored environment.

The bottom line is that the storage of login identifiers and passwords should be a choice based on convenience versus comfort. If the user wants to store their various account login information in a system for quick and easy retrieval, let them, but the service provider should be prepared to accept the burden of responsibility. If the user values the comfort more than the convenience, give them that option. Unfortunately, we live in world where the easy out is to blame the other guy, and proceed to court. There is simply no easy answer here (yet).

Can these services be hacked?

Of course! The moment someone says something is unhackable is most often immediately followed by a moment of apology over a breach. It is the value of the information housed within that service provider that they and their users need to be cognizant of, as the usefulness of the data within the store for a hacker to garner profit from is directly proportional to the amount of effort they (the hackers) are willing to pursue to break in. If the data is segmented by account type, unbranded, and non-personally identifiable, it’s usefulness goes down tremendously.

Is personal identifiable information (PII) being stored with the data?

This is a tough issue to explain to the end user, particularly if said end user didn’t complete their “Introduction to Relational Databases” and “Networks and Information Systems Management” courses. Consumer end-users assume that if they can see their financial data, that the data must somehow be tied to them. To the layman, that IS personally identifiable information – the numbers are money. But “PII” really means data elements such as name, address, phone number, and most importantly social security or tax identification number – elements that tie the numbers (the money) to the person itself. If a system asks me for such information, I generally stop what I am doing and read their privacy policy carefully before I continue. If that information is being stored for later use, I am somewhere between 99% and 100% likely to put the service in the “potentially more trouble than it’s worth” file. If it’s not, I see the risks as no greater than disclosing the same information to a customer service representative over the phone.

The End Note

Again, these are just my opinions, and offering every nuance of this self-prescribed “perfect world” is impossible and likely unprofitable (or at the minimum, a major pain in the ass for some engineers). There is no way to please every user, and there probably never will be. Nonetheless, we’re talking user inputs, service outputs, and wants and needs which are either presently being breached or are yet unfulfilled. And there are a growing number of solution providers jockeying for position, hoping to provide enough answers to get up front.

A Side Note

I’m presently working on some research related to the login/password storage issue, and am looking for some data. In particular, I’m trying to find statistics on internet usage stratified by user type (i.e. core, casual, convenience only, what-have-you), including the number of sites visited daily, login counts, and time spent on sites thereafter. Site types (including blogs, bookmarking, social networking, and financial) would also be helpful. If anyone can point me to something useful in this regard, I’d greatly appreciate it.

Rainbow Hash Cracking

It’s free, and it can crack a complex password in less than three minutes. Dangerous.

Did I mention it was free?

OpenID simplifies recalling online passwords

Simple, succinct description, although that is just one of the aspects of OpenID.

Sys admins should get paid by the password

Systems administrators have too many passwords to remember, so security surrounding them has gotten lax. They simply don’t get changed often enough.

Maybe the enterprise should pay them BY the password?

Purse snatching back in vogue

It used to be you watched out for purse snatchers and pickpockets at the mall, and only around the shopping season. Now you get to worry about them when shopping online. An army of botnets is doing exactly that – snatching personal information while you are loading your virtual shopping cart.

First while banking, and now while picking up Mother’s Day flowers. Well at least its an excuse for forgetting (fear).

Having someone peer over your shoulder to catch your password as you typed never sounded so good.

No passwords, and no fingertips either

There is this very wealthy guy up in Seattle who I admire, but for not for the reasons you think. It isn’t about the money, but the extremely saavy strategies by which he got it, and the way and the and his wife give so much of it away.

OK, I said it. I like Bill Gates, but I don’t like his software. I wish he and his cadre would build something on a UNIX-like platform, show the world he can do the same kind of good technically that he does for the world community, and dispense with the marketing fluff which has and is costing Microsoft dearly.

Case in point, Microsoft wants to dispense with passwords, and is pushing a variety of means to do so. But one thing screws this idea up – FEW trust their products. They license other’s technology and wrap it into funky packaging, then expecting everyone to jump up and down. The latest example of this is their fingerprint capture – what they decided on has already been hacked. This is besides the fact that NOBODY trusts biometrics.

Come on boys – get with the program.
(more…)

Trojans don’t need to steal passwords

Use to be that trojans infected your machine, waited around until you logged into your bank account, and then captured your password for later use. Thieves are on the fast track now – they don’t bother stealing the passwords – they just empty your account while you are logged in.

Microsoft fights spam, while MSNBC enables it

Microsoft is out there, fighting spam like a good software company should, while their partner organizations are building daily challenges for them. Interesting to note the emphasis on “human error” in MSNBC – Editor’s note: MSNBC spam error. When some college dropout tries making a few extra bucks by directing some people to their site with a little internet ingenuity, they get five years in the Federal Pen. When a multi-million dollar joint venture between two multinational corporations does it, it’s a mistake.

What really kills me, however, is the detailed manner in which MSNBC explained the breach. How about giving the bad guys your passwords, boys and girls.

Hmm, well at least they apologized.