Don't believe social engineering can become viral like the latest youtube hamster video? Think again.
From my best count, 12 people every 3 seconds were falling for this. The website is very vague, claiming its safe ...but with whom?! Do people really fall for this? Why yes, yes they do. People want to know who's stalking them ... and yet they can protect their tweets quite easily. Doing a quick look up on them, they're registered via godaddy and their proxy service so you can't really see who they are. Any real service won't do this (yea, I said it, watcho gonna do about it?) so wonder how much damage this will do ... and how many people won't learn there lesson?
Twitter can't stop this either, not without taking out everyone else that's using the API. Might be time for them to issue API codes.
Do you have nice day?! :-)
*** UPDATE ***
Now the site displays the following message
and its straight HTML <center> and the text you see above. So was it a hack of a hack? Hmmmmm interesting. It's too bad they don't have contact info because now I'm curious.
Talked about this during a lunch I went to with Brent Huston (web, twitter) and he asked me had I done a write up on this ... and I haven't so I shall. It's a good piece of info that I think everyone should master - Ask the right question, get the right answer. This pays off in so many ways, it isn't funny and you can use it and abuse it everywhere, in everyday life. This isn't a great theory that doesn't work in reality, this is a basic foundational requirement. Yes, I feel very strongly about this and Brent suggested I should write up how I managed to teach it so here goes.
I hinted at this when I mentioned a good friend of mine, Jay Saunders, was graduating. I tortured him for a solid 2 months (probably more), teaching him this practice. When he started, I told him the number one thing was teaching him how to ask the right questions. Purpose being is multi-layered. First, without asking the right questions, you waste a lot of time figuring out what they (the users) really mean. Second, if you take a minute to think about what you really want, you also should think of the possible reactions of the person being asked -- I will come back to this because there's a lot of nasty pitfalls that need to be addressed. Third, it forces a different thought process and finally, the real goal, it forces the person being asked to NOT give a wrong answer. More...
This is a continuation of my mentoring post made a few days ago but on a more fundamental level. I have no doubt that within every organization, every team and their members are thinking the same thing, but no one is saying it. There's a lot of reasons why and none of them are good. So what's the problem? Communication. People are afraid of looking stupid, asking a dumb question and generally don't want to look like the guy that doesn't know. Well, I usually don't know, so I ask and I've noticed a trend that doesn't surprise me - discussions begin to spawn awesomeness but they're not happening everywhere.
A perfect example came around a few weeks back. I got some time to sit back and learn something so I asked Jon Kruger about what I should be learning next? It's a huge, open ended question but he had a quick, exact response - learn TDD. He didn't say read up on silverlight or ruby or any thing else, he went right for a practice that he's using, regardless of its language. Ok, great, so I asked him "point me in a direction" ... he didn't find anything that was particularly good so, bonus, it spawned a lot of discussions and a few blog posts ...
TDD Starter Kit - Sample Projects and Links
What should you learn next?
Even more important, he did a Lunch and Learn -- we had a full house, around 60 people showed up. That's a great turn out and even better for Jon (people need to listen to him) but when I left I noticed yet another issue ... a group of people, 5 of them were discussing among themselves how they didn't understand where his mocking came from and how his structure map was working because "it was a custom written thing". The fail was simple : They didn't ask. If they would've went up and started talking to Jon about it, I'm sure Jon would have tore it apart and showed them anything and everything -- maybe even wrote a supplement post on it. But they didn't and the general take away was "I don't know how this part works, so I don't need it". Again, this is the fear of asking stupid questions in it's perfect sense.
So what's my point? Start the discussion. Take a chance, ask and find out. The excuse of being silent and pretending "I get it" doesn't apply if you sit back and don't ask. The biggest result that can happen is a wide, sweeping discussion that hashes out a ton of stuff that no one knew everything else is thinking.
My past rash of posts have mostly focused on hardware, servers, linux and other related devices and I'm glad to say, I'm heading back into development. Granted, its VB but its development. So what have I learned in my nearly 6 month absence? Quite a few things, some of which will change my approach on a variety of things. More...
I've recently went through a number of production planned outages of a group of systems we've recently taken over. I like these outages because of that magical word planned. This isn't planned like you put it in your planner and write down a time, no this is a concrete list with no surprises, no unclear roles, everything is laid out and everyone knows what they are doing. This doesn't seem hard and it really isn't, just takes some attention. Being my 2nd or 3rd one on this current project and I'm noticing some good stuff and possible fail routes that can easily be avoided. More...
If the custom module wasn't enough, I'm now wondering off into encryption land. A quick scouting of the System.Security.Cryptography namespace shows me a ton of stuff to play with.
Ooo, AES. I like AES. It runs on my router(s) @ home and is viciously annoying to crack (TKIP f0r t3h w1n!!!11). Cool, let's use that, its good enough for top secret docs for the gov so it should be good enough for me. But, as with anything else, there's a catch or ...20. Here's some basic considerations.
Will this data be searched?
Searching encrypted data is a royal PITA and a huge overhead. Example : saving data to a db with encryption happening in the business layer. A perfectly viable user says to the application "hey, find this" -- you cannot directly ask the database to find it, it is impossible, so every search that happens comes across, ALL OF IT (say 2 million records), decrypts, the search happens, find the records necessary and passes that on. Not very reasonable nor scalable. 2nd option for this is do it on the sql server itself. Fundamentally I have a problem with this for 2 reasons. 1, a purely architecture standpoint, this should never be passed off to the data source. In the real world, it's probably ok to offload some of that overhead, but still, using the OSI model alone says "no no" -- encryption happens in the presentation level and offloading it means you pass though all 7 layers ONCE before you encrypt -- bad bad bad. 2nd, unless the data connection between app/server is encrypted to hell and back itself, your encryption is trumped and effectively worthless.
How much protection is necessary?
The question of the ages. Understanding the CISSP-ism of protection and risk management: the amount of protection spent on it should be equal to the amount of total loss of one breach by the inverse of the possibility of recurrence. So say the data is worth 10 million dollars for ONE loss. The probability of loss is once every 5 years. 10m/5y = 2 million a year should be spent to protect it. No really. Now, if there's no REAL value to the data, ie, its personal junk you keep at home for giggles, then whatever the server can handle works fine. Otherwise, use reasonable + 1.
I'll stop there. Other questions can range from "Who needs access to it?" to "Where will the server be physically housed" -- but thats somewhat outside of the scope of this post. Not saying they're unimportant, just "too much" for this post. I think my first task will be working on getting something simple to encrypt, like a file or a string and work up from there to see how much overhead this thing creates.
One often overlooked aspect of programming is that
evil legal side. Case in point, you are keeping user records of some kind. Now, I'm not talking about SSN, Health Records (HIPPA) or bank info. No, I'm speaking of retaining a users home phone, address, first name, last name, etc. At what point does this fall into the legal consideration category? The answer is "check your local codes". Yea, it sucks, but there's hope.
Within 5 minutes I was able to find the state of Ohio's code regarding (legalese warning!) Private disclosure of security breach of computerized personal information data which is a fancy way of saying if someone steals enough stuff to grant the ability to steal someones ID or other non-public records. The Federal govt has a law(s) for it, but local laws usually reach further and are more clear (as clear as a law can be) as to the actions necessary for this (typically notification and credit monitoring). In this case, here's what the Ohio Law says "Private" information would be... Article 1349.19 section 7 chapter B items 1-4 (I don't make this stuff up)
(b) “Personal information” does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records or any of the following media that are widely distributed:
(i) Any news, editorial, or advertising statement published in any bona fide newspaper, journal, or magazine, or broadcast over radio or television;
(ii) Any gathering or furnishing of information or news by any bona fide reporter, correspondent, or news bureau to news media described in division (A)(7)(b)(i) of this section;
(iii) Any publication designed for and distributed to members of any bona fide association or charitable or fraternal nonprofit corporation;
(iv) Any type of media similar in nature to any item, entity, or activity identified in division (A)(7)(b)(i), (ii), or (iii) of this section.
If you can't get it though normal means (public records, mass media or publication), its considered private information. Still leaves room for "what is public" but something to consider.