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.
