Saturday, December 19, 2009

New MyPay Bookmarklet

MyPay Virtual Keyboard Remover v 2.0:
Works with Firefox, Safari, and Chrome. Drag it to your bookmarks or your toolbar. You need to establish a username and change your password through the virtual keyboard first. Once you have done that, use the bookmarklet to disable the virtual keyboard on subsequent logins.
Before:
After:

Wow, a New Standard for User Interaction

MyPay recently overhauled their interface and made it more "secure." I have my doubts, but they certainly have changed how they interact with the user.


I was a bit speechless. Pleading with users is new, but maybe it'll work for them. Apparently it'll be the only thing working for them:
Although most users have established their new login credentials with no trouble, some users are calling the Central Customer Support Unit for assistance. As a result, customer support is experiencing high call volume, and many customers are waiting on hold longer than usual.

We apologize for any inconvenience this may cause. We are doing everything possible to remedy this situation.
I have a few doubts that "most users" had no trouble. Maybe, just maybe, it's because of your continued use of the ridiculous virtual keyboard. Yes, you've increased the password complexity requirements (which actually increased security), but slaughtered what little usability you had. I promise you that getting rid of it will "remedy this situation."

MyPay, I think it's time that you get rid of the SSO or Admiral/General that once had a keylogger placed on his system and has perpetuated this paranoia. There is a risk/cost analysis that obviously has not been done and is probably costing the taxpayer millions in unnecessary support desk costs. Perhaps using the same standards that the rest of the DoD uses, the DISA STIG, could provide you with a more rational approach for implementing security. I'll even be happy to help you understand all of the super-secret requirements that are available on their website.

I'm just sayin'...

Tuesday, November 10, 2009

myPay Simple Log In


To finish my rant started in my previous post, I've put together a simple proof of concept bookmarklet to remove the myPay virtual keyboard security facade. To use it, drag the below link to your bookmark bar (works on Firefox, Chrome, and Safari).
Go to https://mypay.dfas.mil and click the new bookmarklet. Your login dialog should remove the virtual keyboard and allow for a simple log in.
Just to be clear, this doesn't allow you to do anything that you couldn't already do- myPay allows you to do a simple login if your virtual keyboard login fails.

Monday, November 9, 2009

myFail Web Site

Logging into the DFAS myPay site is frustrating. This is the gateway where DoD employees can view and change their financial data and records.

In an attempt secure the interface (namely to prevent key loggers), they have implemented a javascript-based keyboard where the user must enter their PIN using their mouse (or using the keyboard pressing tab LOTS of times). A randomization function is used to change the position of the buttons, presumably to prevent a simple click-tracking virus from simply replaying the click sequence. Numbers always appear on the upper row and the letters will appear in a random position on the same row where they exist on the keyboard (e.g. QWERTY letters will always appear on the top row, just in a random order).
At first glance, I assumed that there would be some server-side state that identified the position of the buttons (as to not allow the user's browser to arbitrarily choose the positions). Looking at how the button layout is generated, however, makes it clear that the position is indeed generated by the client-side alone. Javascript functions are called to randomize the locations, and the locations of these buttons are included as part of the POST parameters upon authentication. A visOrder variable is included with a simple substitution cipher to identify button locations: 0 is represented by position 0, 1 by position 1, etc. Thus:
VisOrder =3601827594
Substitution =0123456789
Example PIN =325476
Encoded =102867
Thus any virus/program can easily mount an online guessing attack (since it defines the substitution pattern), and can quickly decipher the PIN if it has access to the POST parameters.
The web site's security implementation is painfully trivial, so we can conclude that the Javascript keyboard is only to prevent keyloggers. But it has a number of side effects, especially with respect to the security of the password. Given the tedious nature of PIN entry, users choose extremely simplistic passwords. MyPay actually encourages this as it does not enforce complexity requirements and limits the length of the password between 4 and 8 characters. There is no support for upper/lower case or special characters. 36 possible values over an 4-character search space is not terribly secure.
I think that myPay has allowed their paranoia about keyloggers to overtake reasonable design and security decisions about the rest of their system. A system infected with such a device or software has been critically compromised anyway, and will have access to at least system-level passwords and the SSN of the user logging into myPay (the SSN/LoginID field is not protected by the virtual keyboard function). It is an insight to the simplistic view of security that too many hold, and also has the unfortunate manifestation in a terribly unusable user interface.

Red Hat gets it right...

Couldn't say it better myself, so I'll simply call out their argument (citations removed):

It is, however, practically impossible to know with reasonable certainty whether a new software product could be said to infringe some prior software patent. Patents are conventionally referred to as intellectual property. However, as James Bessen and Michael Meurer have explained in detail, patents differ substantially from tangible property in that their boundaries are often fuzzy and unpredictable. If patents do not give clear notice of their limits, they create a risk of inadvertent infringement. Vague patents also enable opportunistic behavior. For example, a patentee may, based on vague language, claim ownership of a technology unknown to the inventor, but instead first conceived by someone else.
This problem of uncertain patent boundaries is particularly acute with software patents. Software is an abstract technology. Software algorithms can be represented in numerous different ways, and even computer scientists sometimes disagree over whether two software technologies are equivalent. Thus it is not surprising that software patents are typically framed in abstract language with uncertain boundaries. As a result, a software developer, when shown a software patent, often cannot be sure whether the patent reads on newly developed code.
This difficulty is multiplied hundreds or thousands of times with regard to a complex software product combining hundreds or thousands of discrete components. A separate but related problem faces all software developers—that of the impossibility of patent clearance, or determining whether there are existing patents that may be said to read on a new product. There is no reliable, economical method for searching the hundreds of thousands of existing software patents. The clearance problem is made even worse by the existence of tens of thousands of applications that for eighteen months after filing are unpublished.
Thus, simply by virtue of producing and marketing an innovative software product, a software developer assumes the risk of a costly patent infringement lawsuit. In the U.S., software patents are more than twice as likely to be the subject of a lawsuit than other patents and account for one quarter of all patent lawsuits. The cost of defending a patent lawsuit frequently amounts to several million dollars. Such lawsuits involve technical issues that are difficult for judges and juries to understand, and so even with a strong defense the outcome is usually far from certain. If there is a judgment of infringement, the penalty may be an injunction ending further production and enormous monetary damages. Defense costs and litigation risks are so large that in most cases defendants agree to some payment to settle such cases. Even when claims appear to have no valid basis, targets frequently agree to pay for licenses based on the mere threat of litigation.

Software Patents (Bilski v. Kappos)

I just learned about this case while listening to CNBC, but the implications to the entirety of the software world are huge. I should preface this post with the fact that I AM NOT A LAWYER and this is simply a statement of my opinion.

Bilski v. Kappos is a case currently before the Supreme Court of the United States (SCOTUS) regarding the patentability of an idea without a tangible implementation. Scotus wiki summarizes:
"In seeking a patent, Bilski and Warsaw told the Patent Office in 1997 that their idea was a highly useful one: using complex mathematical formulas, they could tell a business how to hedge against risk due to the rising and falling of prices of raw materials that were used to produce something — say, to generate electricity. Commodities prices often fluctuate quite widely, because of market forces or even changes in the weather, so these two inventors figured out ways to manage what they called “consumption risk.” It is, they claimed, of benefit both to businesses and to their customers."
This hedging strategy was rejected by the patent reviewer because it was not a concrete implementation of an idea, simply a concept. Courts have long held that mathematical axioms or algorithms are not patentable, as they are part of natural law. The most recent affirmation of this by the appeals court identified that an idea must be tied to a particular machine or apparatus or be involved in the transformation of an article to a different state to be patentable. This is now referred to as the "machine-or-transformation" test when considering patentability of an idea. The appeal before the Court aims to overturn this decision.
This has huge implications on the software industry as a whole. In an age where companies patent the most simplistic and abstract of ideas in hopes of future infringement, often the creation of new standards and technology is painfully inhibited by attempts to avoid such Intellectual Property (IP) traps. Companies rush to artificially build an IP war chest to hedge their inevitable infringement on others' IP. The number of trivial and otherwise trite patents that exist in this realm is simply staggering, and it is nearly impossible to develop without a devil-may-care attitude regarding infringement. It is a nightmare for any software development effort and for the engineers associated with them.
Similar, Donald E. Knuth, Professor Emeritus at Stanford University and one of the world’s most respected computer scientists, wrote in 1994, “When I think of the computer programs I require daily to get my own work done, I cannot help but realize that none of them would exist today if software patents had been prevalent in the 1960s and 1970s.” ... Dr. Knuth also stated, “I strongly believe that the recent trend to patenting algorithms is of benefit only to a very small number of attorneys and inventors, while it is seriously harmful to the vast majority of people who want to do useful things with computers.”
This quote, offered by the RedHat's amicus brief in support of affirming the decision, captures the essence of the problem. RedHat's argument is well-reasoned and is worth a read if you can ignore the painfully verbose, legalese nature of the document. Be sure to read the various arguments on the Scotus Wiki and keep track of the eventual decision from the Court. Also note who filed amicus briefs in support of the petitioner (i.e. Overturning the decision) vs. supporting the respondent (Affirming the decision).

Monday, November 2, 2009

Trouble with Windows 7/Internet Explorer and CAC?

Just a quick note about something I discovered- After upgrading my Windows XP virtual machine to Windows 7 x64 Professional, I was no longer able to access sites which required a DoD Common Access Card (CAC). Tinkering with Wireshark and Google Chrome finally appeared to reveal an answer: Windows 7 x64 (and possibly other versions, I don't know for sure) doesn't want to present a client certificate over anything but SSLv3.0.

So if you're having problems, be sure to go to Internet Options -> Advanced -> Security (Bottom of the list) and uncheck everything but SSLv3 as supported. That should reenable CAC authentication to DoD PKI websites.

Wednesday, September 9, 2009

Protocol Handling in Mobile OS's

I'm rather interested in the possibility of writing an application for a popular mobile OS (i.e. Apple iPhone, Palm WebOS, Google Android) which can capture and handle links of a particular protocol within the web browser. This isn't that uncommon- this occurs every time you hit a custom protocol link, such as mailto:// or vnc:// which launch an email or VNC client, respectively. This is an important concept for inter-process communication, especially as the line between native application and web application become increasingly blurred (WebOS!).

iPhone: Interaction between applications and mobile Safari is possible, as demonstrated by Alocola. Applications register to handle links, and can also issue GET requests through the browser.

Android: It's possible to register an intent-handler within your application, though it it appears to only be relevant for non-webkit based interactions. For whatever reason, clicking custom protocol links fall flat.

WebOS: It doesn't appear to be possible. There's a resource file that maps internal applications to protocols, but it appears to be a reference and not modifiable.

The other thing I noted about WebOS was that while the javascript capability exists for novel application development, it is absolutely no replacement for a true application development framework. Why? There's no graphics abstraction API, persistent storage capability is extremely limited, and there's no networking except AJAX calls.

Monday, August 17, 2009

Lots of explanation...

But no useful information. GPush FAQ:

Should I be concerned about providing my password to GPush?

When we created the app, we committed first and foremost to security. We are using multiple levels of encryption including SSL, obfuscation, and cipher-based encryption. SSL ensures that your credentials can be transported securely. Your login credentials are encrypted using an encryption scheme that has never been cryptographically broken, with a different 'secret key' for each user. To test these security measures, penetration tests were ran on the server with no information accessed.


So what's the problem with this explanation? Nearly everything- the use of SSL is the only really useful piece of information, since we know what ciphers GMail supports. On the other points:
  • Obfuscation: This could mean anything, even that they named sensitive files as grandmasGroceryList.txt to throw off hackers.
  • Encryption scheme never been broken: This, again, means nothing. It is some custom scheme that has never been analyzed? I don't want someone's ROT-13 encoder protecting my personal information.
  • Different secret key for each user: How are these keys generated and stored? How is this key repository stored to prevent unauthorized access? Is it done in such a way that this is this better (security) than having a single key for each user? Probably not. More than likely, it is just another level of indirection.
  • Penetration tests: Professional? Script kiddy? State-sponsored? Automated tools? What level of access was given, and what testing procedures were followed?
If we are expected to believe that the due diligence was performed in the creation of this utility (especially the server-side components), this information shouldn't be hard to provide. Identify the ciphers. Detail the encryption process and the defense measures put in place. Provide some context regarding the testing procedures.

Or don't provide that data at all. It may prove less troublesome in the end. Because with good encryption or not, allowing someone to have your credentials (impersonation) is potentially dangerous. You just have to weigh the benefits of the solution against the cost of having to change your GMail credentials and the relatively low possibility that someone gets access to your account.

Monday, August 3, 2009

iPhone Hate

Let the pain begin.


The last two points are a bit weak, but it does call out that there are *much* better options at this point.

And yes, I have an iPhone. Hopefully not for much longer.

Tuesday, July 14, 2009

Compromised CA

A lot of people don't realize how sensitive and delicate PKI is in practice- this is the technology behind much of internet security (e.g. SSL). Though we can theorize that it would take 100's of thousands of years to brute-force an security system, that's never the attack vector (or point of vulnerability) on such a system. This does actually happen; the German healthcare system suffered such a problem when it's CA (certificate authority) lost it's keys after a power outage. Now, they must start from scratch, reissuing over 80 million smart cards. While it may seem overzealous to reissue that many cards- after all, the CA key was lost, not stolen- it's important to realize that without the CA's key that is impossible to issue new Certificate Revocation Lists (CRLs), create new Registration Authorities (RAs), etc. The PKI system instantly become useless. You have to start over.

Monday, May 4, 2009

That's why my identity got stolen!

Slashdot points at a recent research paper regarding an infiltration of the Torpig botnet. The sheer amount of data that the botnet collects from the infected nodes is staggering- Roughly 180 thousand infected nodes and enough financial information to steal up to $8.3 million. Running a secure system may not even be enough to protect you, unfortunately:
While 86% of the victims contributed only a single card number, others offered a few more. Of particular interest is the case of a single victim from whom 30 credit card numbers were extracted. Upon manual examination, we discovered that the victim was an agent for an at-home, distributed call center. It seems that the card numbers were those of customers of the company that the agent was working for, and they were being entered into the call center’s central database for order processing.

Monday, April 20, 2009

Check your SSH logs...

Cause everyone's trying to get in. From my home router logs...


Apr 19 07:47:30 unknown authpriv.warn dropbear[6815]: login attempt for nonexistent user from 202.96.50.240:41238

Apr 19 07:47:31 unknown authpriv.info dropbear[6815]: exit before auth: Disconnect received

Apr 19 07:47:31 unknown authpriv.info dropbear[6816]: Child connection from 202.96.50.240:42789

Apr 19 07:47:35 unknown authpriv.info dropbear[6816]: exit before auth (user 'root', 1 fails): Disconnect received

Apr 19 07:47:35 unknown authpriv.info dropbear[6817]: Child connection from 202.96.50.240:44292

Apr 19 07:47:38 unknown authpriv.info dropbear[6817]: exit before auth (user 'root', 1 fails): Disconnect received

Apr 19 07:47:39 unknown authpriv.info dropbear[6818]: Child connection from 202.96.50.240:45872

Apr 19 07:47:42 unknown authpriv.warn dropbear[6818]: login attempt for nonexistent user from 202.96.50.240:45872

Apr 19 07:47:43 unknown authpriv.info dropbear[6818]: exit before auth: Disconnect received

Apr 19 07:47:44 unknown authpriv.info dropbear[6819]: Child connection from 202.96.50.240:47601

Apr 19 07:47:47 unknown authpriv.warn dropbear[6819]: login attempt for nonexistent user from 202.96.50.240:47601

Apr 19 07:47:48 unknown authpriv.info dropbear[6819]: exit before auth: Disconnect received

Apr 19 07:47:51 unknown authpriv.info dropbear[6820]: Child connection from 202.96.50.240:49411

Apr 19 07:47:54 unknown authpriv.warn dropbear[6820]: login attempt for nonexistent user from 202.96.50.240:49411

Apr 19 07:47:55 unknown authpriv.info dropbear[6820]: exit before auth: Disconnect received

And this goes on for about 10 minutes.

Wednesday, April 15, 2009

Yet another reason not to use ATM cards...

As if you needed more reason not to use ATMs, now it's revealed even using a perfectly secure machine is still dangerous due to poor security practices on bank networks:
According to the payment-card industry, or PCI, standards for credit card transaction security, PIN numbers are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple [Hardware Security Modules, HSMs] across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API.
"Essentially, the thief tricks the HSM into providing the encryption key," says Sartin. "This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device."
Sartin says HSMs need to be able to serve many types of customers in many countries where processing standards may be different from the U.S. As a result, the devices come with enabled functions that aren't needed and can be exploited by an intruder into working to defeat the device's security measures. Once a thief captures and decrypts one PIN block, it becomes trivial to decrypt others on a network.
To be fair, the article title is unnecessarily inflammatory since this doesn't involve cracking the actual PIN, but simply exploiting flaws in the design (no one is cracking crypto in this case). There is no legitimate cause for this type of problem nor a need to decrypt at various points in the network- it's kowtowing to backward compatibility concerns that is causing a problem like this.

Either way, though, it's time to think twice before putting my ATM card into the that sketchy gas station ATM. And use the credit card feature of your check-card if you have them. Refuting an ATM transaction is so much more difficult than a fraudulent credit card transaction.

Friday, April 10, 2009

TSP and Up(?)time

Okay, the TSP site is something that is reminiscent of the late 90's with regard to site design, but it's something that has been sufficiently functional for my needs. Apparently, however, their UI isn't the only thing that is a relic:

Three days of downtime for "system maintenance?" What would the reaction be if a commercial financial site (e.g. Scottrade, BoA, etc) were down for three days?

Thursday, April 9, 2009

Viscosity, OpenVPN and DNS Priority

I wanted to change my DNS settings when connecting to an OpenVPN server using Viscosity. Using the resolv.conf and other methods didn't seem to have any effect, so I put together a solution that seems to work.

First, put these scutil commands into a file (we'll call it /usr/local/bin/changeDns.pref):
get State:/Network/Service/0/DNS
d.add ServerAddresses * 192.168.1.1 10.0.0.1
set State:/Network/Service/0/DNS
Notice that the ServerAddresses line has my DNS servers in order of priority. Change this to match your desired DNS resolution configuration. This settings will be automatically undone once the connection has been severed.

(Edit: The /Network/Service/0/DNS line is from my configuration, but it apparently varies between computers. You may need to run the scutil command list State:/Network/Service/[^/]+/DNS to find the name of your DNS service. Citation here.)

Now, we need to edit the /Applications/Viscosity.app/Contents/Resources/dnsupalt.py file (the script which is run when Viscosity connects). Put this after the nameservers and search_domains line:
#!/usr/bin/env python
# Viscosity DNS Support Script
# http://www.viscosityvpn.com
import os, re, sys

nameservers = []
search_domains = []

os.system("scutil < /usr/local/bin/changeDns.pref")
This tells scutil to run the file upon connection. Running scutil --dns after connecting shows that the DNS servers have been updated:
resolver #1
nameserver[0] : 192.168.1.1
nameserver[1] : 10.0.0.1
order : 200000
Disconnect and the system goes back to the DNS server offered by DHCP:
resolver #1
nameserver[0] : 10.0.0.1
order : 200000

Thursday, April 2, 2009

Slingplayer for the iPhone

Count me in as "disappointed." I was really looking forward to using my iPhone to access my Slingbox when the mobile application came out (and had even convinced myself that the $30 would be worth it), but that's not a concern anymore since Sling has decided that they're arbitrarily removing support for non-pro devices. I miss the days when companies encouraged upgrading by adding features, not by simply deprecating their previous product line.

Dumb move on their part, but it's at least one less thing to waste money on.

Wednesday, April 1, 2009

Using google talk as a logging mechanism

So there's been an interesting side effect of using Jabber (specifically, Google Talk) to act an interface to the home automation system- logging. Google Talk allow for messages to be sent to offline contacts; these messages are saved and stored in the normal "Chat" dialog in the GMail interface. Since the automation system sends state notification to Google Talk, all of the messages are automatically archived in my account.


This is a nice little side effect. It provides a timestamp based on the browser's time zone and nearly ubiquitous access to the information. I also imagine that it'd be rather difficult to tamper with the timestamps. I now have a record of my garage door activity for the last several weeks (and indirect proof of my lack of a social life- I don't go out much apparently). My 9:30 Taco Bell run also will live in infamy.

Tuesday, March 3, 2009

House rules...

rule "Close Garage Door"

when

event : TimeEvent()

garageDoor : GarageDoor(doorOpen == true)

jabber : JabberAlarm()

then

garageDoor.closeDoor();

log.info("Closed garage door by rule on " + new Date());

jabber.sendNotification("Closed garage door by rule on " + new Date());

end


It keeps me from letting all the riffraff in when I leave the door open at night. Thanks drools!

A conversation with my house


It even cleans up after me. :) In case it's not clear, I'm the penguin. I'm just speaking in javascript.

Wednesday, February 25, 2009

eBay and Reputation

Stories like this demonstrate how broken the eBay/Paypal system is. I've been trying to think of a practical solution to fully fix the business model to no avail. Escrow services seem to be the only way to be reasonably protected but that scales poorly, is costly, and is difficult for high-tech or esoteric transactions.

eBay is one of the first and most successful examples of a reputation-based identity system, yet is still remarkably flawed. Is it because people are naive to the concept of reputation, greed/ignorance leading them to carry out deals with people with no/poor feedback, or reputations simply not being relevant to peer-to-peer commerce? Such systems will never fully defend against someone willing to throw away their identity to score a quick buck, but the anecdotal evidence is everywhere and eBay's reputation as a scammer's haven is becoming solidified.

The above story doesn't detail buyer's feedback, but it is definitely relevant.

Wednesday, February 18, 2009

Facial Recognition and Biometrics

Slashdot points to an article describing the "cracking" of facial recognition software used as an alternative login for some laptops. It may be a liberal use of the term "cracking," but it's yet another reason why biometrics should be used sparingly (if at all) and as a single factor in a multi-factor authentication system. It's just too easy to capture and reproduce human qualities that most biometric readers will believe. Try revoking those credentials.

Someone in the identity movement should contact Hollywood and tell them to knock off the sci-fi authentication schemes. I'm convinced that is where much of this biometric craze originates. Isn't painful to watch a show where biometrics provide the "strong" security (which actually offer trivial protection), and the next scene has a ciphertext or firewall being cracked in seconds? I'm talking to you, 24.

Sunday, February 15, 2009

Face Detection and iPhone Video Streaming

I recently purchased a Linksys WVC54GCA WiFi camera. It's a wonderful little camera, but my primary reason for purchasing it was to be able to stream video to my iPhone; it uses Motion JPEG which is the only video option available in Mobile Safari. It actually works very well, though my intention is to eventually attach it to my iRobot Create to give it "vision." More on that later.


Anyway, despite the camera's strengths, there are a few limitations. First, the camera can only support 4 simultaneous clients and the performance degrades linearly with each additional client (from my anecdotal experience). Second, the only access control the camera offers is HTTP Basic Authentication backed with a 4-user list configurable from its web interface that doesn't integrate well with any other application or security system. I figured that the best and most direct way of fixing the problems was to proxy the feed through my MacPro to manage the connection and user access there instead of on the camera.


As I was imagineering this system, I also got the bright idea to go ahead and do facial detection (not recognition -yet-) on the stream. After doing some research on the technology, I decided to use the OpenCV libraries developed by Intel and subsequently open sourced. My initial prototypes were extremely slow (1-2 FPS) since the Java libraries depended on JNI calls to a non-thread-safe C library. I did more research and found the Faint (Face Annotation Interface) library which did Haar in pure, multithread-able Java. (I had to take the beta code from the SVN since it wasn't released yet.) That finally got me a much more acceptable 10+ FPS.


Now I have the camera stream being cached within a custom-built Tomcat webapp that does the detection and also provides security for the stream. It can support much more than the 4 users available from the camera and without a FPS hit. It's pretty cool. Right now it just draws a red rectangle around the detected face, but obviously more triggers and actions are possible and desirable. It should definitely be noted that the stream (with facial detection) is viewable from the iPhone! Now- to just get the damned thing attached to my iRobot and my little mobile sentry will be complete. :)




Friday, February 6, 2009

dscacheutil -flushcache

I've been needing to flush the DNS cache on my Mac a lot lately. (Possibly due to VPN hackery) Anyway, the nice little utility for OSX to flush the DNS cache (dscacheutil) is okay, but I'm pretty sure that it also flushes out any Safari cookies/sessions too. Isn't there a less destructive command for clearing the DNS cache?

Monday, February 2, 2009

The weakest link


Sad but true. Probably could be have had countless other punchlines, like "let's have a hot-sounding girl call him up and ask him" or any other socially-engineered password harvesting technique.

Sunday, February 1, 2009

Zoombak Dissection


I've had a lot of fun with the Zoombak GPS device. Ever wonder what's inside one of those little guys? I did, but couldn't find any images on the internet to satisfy my curiosity. So I dissected mine.


It uses a 3.7V 890mAh battery, a Siemens 133851-V02 cellular chipset, and a Cirocomm 574B GPS module. As suspected, you can clearly see the holder for the T-Mobile SIM card (which I've already removed).

Saturday, January 31, 2009

Weak vs. Strong Password (On a sticky)

"Be sure to write down the insane password it generates for you (below), as a weak password would be far worse than a strong password jotted down on a sticky note next to your PC."
Is this the logic we use now when it comes to password management?


Thursday, January 29, 2009

Infocard Transaction (Becoming?) Possible on iPhone

I think this is a big step forward for identity federation on the iPhone, mainly because it's the merging of two subjects I find rather interesting. I'm not a big Objective-C developer, but reading MobileOrchard's post on protocol handlers within the iPhone SDK gave my brain a kick-start this morning.

Imagine this: As described in previous posts, you encounter a page with an infocard:// link as the login button. That kicks off an iPhone InfoCard selector application, which retrieves the WS-Mex data from the RP page and then interacts with the chosen IDP using WS-Trust to retrieve a token. The retrieved token would ideally then be POSTed to the RP within Safari, but apparently Safari won't deliver app-formed POST data yet. So the last piece of the puzzle would be to either URL-encode the token (yuck), or do some kind of artifact retrieval (equally bad if not worse).

Monday, January 26, 2009

Monster.com Security Breach

Absolutely disgusting. A company's (lack of) security allows a data breach, and they cavalierly dismiss it as a price of doing business.

As is the case with many companies that maintain large databases of information, Monster is the target of illegal attempts to access and extract information from its database.

Which should have actually said: "As is the case with many companies that maintain large databases of information, we failed to take the proper precautions to secure your information against unauthorized access and theft." It's even worse they they don't intend to email users about the breach. The solution they provided offers little comfort.


It is important to know the company continually monitors for any illicit use of information in our database, and so far, we have not detected the misuse of this information.


If the information has been accessed (and probably copied), how do they intend to detect/prevent the misuse of information? Maybe they should enter the DRM space if they've got the solution.



(from: http://help.monster.com/besafe/jobseeker/index.asp)