Hi Kuba > But going back to the point of my original email, does anyone know of any other good standalone HTML apps?
The only other one I know is Wiki On A Stick from Paul Levey (who also maintains TiddlySaver.jar that is shared with TiddlyWiki): http://stickwiki.sourceforge.net Best wishes Jeremy On Mon, Mar 31, 2014 at 9:55 AM, Kuba Kabacinski <[email protected]>wrote: > Mario, > > Frank assessments can sound aggressive, but pointing out issues leads to > better outcomes for all :-) Like all other software, EveryPass has > vulnerabilities, but being open about security risks should enable people > to determine whether it meets their needs. > > We'll add some more info on hashing on our web page soon (I usually use > Linux command line to do this). > > In terms of using our Validator service I understand that many users will > be reluctant to do this. The import functionality achieves the same outcome > for the user and we explicitly enabled a workflow which frees you from ever > having to return to our website as long as the user gets good original > copy. We wanted to make EveryPass free in as many ways as possible ($0, > open source, standalone, optional services and executable on as many > devices as possible). > > Weak password detection and timeouts to minimize user "self harm" will > feature in the next release. > > But going back to the point of my original email, does anyone know of any > other good standalone HTML apps? > > Kuba > > > On Sunday, March 30, 2014 2:06:13 AM UTC+10:30, PMario wrote: >> >> Hi Kuba, >> I also appreciate your response. ... After posting it I thought I was a >> little bit to aggressive ;) >> >> On Saturday, March 29, 2014 2:08:59 AM UTC+1, Kuba Kabacinski wrote: >>> >>> There has been a topic about TW5 as a password store. My opinion [1] >>>> about an html app as a password store has not changed very much. >>>> >>>> I definitely think, that a single purpose app is less vulnerable, if >>>> always loaded from https, than a "framework" like TW5, which is designed to >>>> include all sorts of 3rd party plugins. ... I think it is a good move, that >>>> you inform your users at the "Security" section of your page [2], about the >>>> pro and cons. >>>> >>> >>> The primary usecase is to load it from your file system and we assume >>> that you trust the device you are using. >>> >> Our intent is to provide a more portable option for password management >>> rather than replace the good existing solutions. Security is about managing >>> risk and the level acceptable in one situation may not be in another and >>> part of this is articulating the risk properly. >>> >> >> OK. >> >> >>> You provide 2 checksums on your page, that should make users feel save >>>> but in the text you write, that these 2 values are broken in the second I >>>> use the program. >>>> - So what's the value of those checksums? >>>> >>> >>> If you happen to download EveryPass from a 3rd party (like all the >>> download websites out there) you can verify if it is original or not. Our >>> assumption (right or wrong) is that if someone understands what the >>> signatures are they've probably verified software authenticity that way >>> before. For others (probably the majority) they are useless. >>> >> >> I think a local link with some more info would be nice. This second page >> may have an external link to verification software you would recomend. Or >> if you don't want to link away from your page. Just use propper names, and >> google should find it :) .... I personally wouldn't want to send you a >> file with all my (encrypted) data, for verification. ... I just wouldn't. >> >> >>> >>> >>>> - If I download an empty version, how can I locally check the >>>> integrity (How can I calculate the checksum of a file?) >>>> >>> >>> There are a number of hashing programs available, perhaps we should make >>> it more overt that when you download from Consunet over HTTPS you don't >>> have to check because the channel guarantees integrity. >>> >> >> I think https should be default ... but until it isn't, I think it needs >> to be made clear for every user. >> >> >> >>> >>>> ------------ >>>> I did play a little bit with the browser dev console. >>>> >>>> I think plain text passwords should _not_ be stored in the DOM, longer >>>> as necessary (<10 seconds). It's too easy to read them, with a one liner >>>> and a little bit of "getElementsByTagName" >>>> >>> >>> EveryPass relies on the browser sandbox to prevent cross domain access >>> (other websites scraping forms). If this is broekn we should all should >>> stop using the Internet now. >>> If you have some software on your device which is scraping your browser >>> input fields I'd suggest that you're already compromised. Doing anything to >>> hide passwords whilst EveryPass is running is next to pointless because the >>> attacker has probably scraped your master password first and it is very >>> much game over. In my opinion hiding stuff for 10 seconds or some other >>> time is just "security" through obscurity. >>> >> >> I thought you should remove all data from the DOM if the user clicks the >> "hide" button. Or after eg: 10 seconds. >> >> I'd like to add a 3rd attack vector. .. "A trustful user". >> - The user is away from the computer. >> - The software is running and the data is decrypted and stored in the DOM >> - Someone comes and opens the dev console and types: >> var all = document.getElementsByTagName("input"); for (var i=0; >> i<all.length; i++) { console.log(all[i].value) } >> >> You get the whole stuff in plain text. ... IMO this shouldn't be >> possible. .. but this behaviour may be gone when you do the countdown ... >> >> There is no count down, that "re-encrypts" the stuff. ... So if I change >>>> the browser tab and leave the pc, everything is there to be used. ... >>>> >>> >>> We do intend to fix this :-) https://github.com/Consunet/Apps/issues/4 >>> >> >> I did see this issue, after I did my post :) >> >> >> >>> I think: "havefun" as a pw is not OK and "havefunmario" is not a strong >>>> password, even if the app thinks so. >>>> >>> >>> We know we need to work on our password strength alg, this will come >>> when we add password generation functionality. >>> >> >> Yea, would be great. >> I think the biggest problem here is "weak user defined passwords". It >> doesn't matter, if AES is secure, or if the user trusts his/her system. If >> an attacker got the file, and it is possible to break the password with a >> "brute force" attack. ... >> >> >> have fun! >> -mario >> > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/tiddlywikidev. > For more options, visit https://groups.google.com/d/optout. > -- Jeremy Ruston mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
