--On Monday, April 04, 2005 1:29 AM -1000 Aaron Kagawa <[EMAIL PROTECTED]> wrote:
Philip,
I just noticed a security flaw in the Hackystat web application. When I click on links in the user interface the URL stays in the Browser's URL cache. This URL usually contains the Hackystat 12 digit Key. Not to mention that the Browser's Webpage History Cache. Therefore, I could go up to anyones browser and find their Hackystat Key. Well, I suppose it would just be way easier to just look at the users' .hackystat folder.
I suppose this is not a high priority. But, this issue's severity is probably very high; privacy is always an issue.
thanks, aaron
Hi Aaron,
Yes, this is indeed a shortcoming of the current design. Of course, there are a wide spectrum of privacy-violating things you can do "if you can go up to someone else's browser". For example, if I was reading email using the UH web mail client (with state of the art security, https, password encryption, etc.) and you got access to my browser within 20 minutes, you could press the back button, get to my inbox page, and read all of my email.
So, on the one hand, providing privacy under the assumption that others will have access to your browser is quite difficult. On the other hand, Hackystat is of course far easier to hack than UH Webmail, since there's no time limit on when the cracker would need to get access.
I think there are two ways this problem will be resolved over time:
(1) Hackystat goes "behind the curtain", for example with Ikayzo. In this case, Hackystat becomes a back-end application for some larger service, and the user interacts with the service's front-end, which then retrieves data/charts from Hackystat and provides it back to the user inside a different interface. In this case, even if the user installs sensors and knows their user key, if they don't use the default Hackystat interface to retrieve data, then the privacy problems you speak of are replaced by whatever privacy mechanisms are in place with the service.
(2) Hackystat is changed to incorporate a more standard password mechanism. This has been on my to-do list for about four years now. :-) It's never reached a high enough priority: while it's been noted as a usability problem in the past, there were other usability problems far more severe than that one. In the best of all possible worlds, it will become one of the most important usability problems within the next six months to a year, and we'll fix it. It's not a trivial change, there's lots of implications for testing and so forth, but at the same time I believe that it's less complicated than evolutionary SDTs, for example.
Cheers, Philip
