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.
