My1

well I wasnt asking about when we will see it, I was just curious why it isnt possible yet.

may I ask WHY icloud sync is only possible on apple devices?

@Speedys1979 good keycards shouldn't even give out the key and be uncopyable.
that's for 1 reason.

if you can copy a key card you can return it and attack later without the victim even knowing the card has been copied.

if it cannot be copied, the attacker needs the real card thus allowing the victim to notice and possibly revoke the card.

generally any "possession" factor should be unique and tamperproof (or at least tamper-evident to e.g. kill the key if someone tries to get it).

On 16.10.2016 at 9:56 AM, Ivarson said:

For my primary email I only store the TOTP in Enpass,not the password

well in that case it's okay

On 16.10.2016 at 9:56 AM, Ivarson said:

which is unique from other password but not as complex,so I have no trouble memorizing it. 

I know that feeling, I am same.

18 hours ago, ithinkiam said:

Hi @my1

It's mostly financial websites that do this (banks, credit card, etc). I also had this when calling up my ISP recently. 

well my bank never does this, and I am happy about it.

especially because if they ask for specific characters of the password there are only 2 ways of doing it.

1) do it after you entered your password (plaintextpw may still be in ram or whatever, I sure hope it's probably wiped afterwards)

2) store the password in a retrievable form. which is OBVIOUSLY bad because a machine-retrievable password means that as soon as someone gets access to the machine, you can screw any last security measure that prevents bruteforcing, because the machine needs the PLAINTEXT pass to probe certain chars. and if the machine itself can access teh passwords even if they are encrypted that means that the machine has access to that key, which obviously means that an attacker can as soon as he is in the server near-effortlessly access ALL PASSWORDS IN PLAINTEXT!

If I were you I would seriously ask that provider to talk about how they store the passwords, because if it is scenario 2 where you dont enter your full pass but the subset only they are literally just asking for trouble. this is even worse than the Yahoo hack which had md5 for passwords which is albeit not really secure, at least needs the attacker to bruteforce or rainbowtable it, but in scenario 2 the attacker gets the PLAINTEXT passwords literally served on the silver tablet (at least that's how we would say it in german, dunno if that works in english).

@Jones1024 regarding attach checkbox, a better Idea would be to have a way to say up to what size attachments are synced (possibly even with a split for mobile vs WLAN) but that comes after they made multiple files for the storage, I guess.

regarding the splitting of files and stuff: they said they will take the monolithic one "FIRST", in other words they probably will someday go to multi-file sync, although due to the time factor, monolithic is going first (I guess it's easier).

may it be possible to kick those auto-backups right into the cloud of choice?

wouldnt it be possible to check what enpass's state is by checking the RAM?

well as I said one thing enpass could do would be wuto searching its owm directory for the db and if it's there just use it

why do you need an ext partition to run enpass portable on linux? sorry I dont understand.

but one thing it could do for people who dont use it cross platform would be an option to just contain itself entirely. or search for the db inside the enpass folder, if it's there, default to it, if not do as it is now.

and I use enpass portable on the work PC on the harddrive either but I like portable software since they are entirely self contained meaking it easy to remove them without traces (I know that there's recovery software and stuff but that's another story).

and for people using enpass portable on system I also think it makes more sense that those people have the data inside the enpass directory because that's how pretty much all the portable softwares work.

@Ankur Gupta but couldnt enpass portable just use relative paths?

thereby staying entirely contained in itself without the user even having to do anything

and even if using relative paths directly wouldnt be an option it could be possible that enpass determines its path for itself and then builds abolute paths upon that.

@Yogesh Kumar okay, I will check when I see something incoming for firefox.

okay I can understand the performance issue but is it at least possible that the button changes a bit to show the user that he can do autofill on the page (like the number of strored credentials etc for that page)?

why is that file in my user folder?

isnt the whole point of a portable application that it is ENTIRELY contained in its application folder?

This also heavily relates to the issue that enpass cant just do its database file automatically in its own folder.

http://www.android-hilfe.de/ also doesnt work, btw

but is there a way to let enpass tell the user that it can do filling (or just fill it without sending the form?

always having to rightclick->enpass seems a little bit weird.

but at least now we have the code for the entire enpass database format, which is great.

would certainly not be bad.

I think that the tray icon as it is is pretty bad. if you have in general a dark theme you probably need the white icon but the problem is as soon as enpass moves out of the items from the taskbar into the extra window WHICH HAS WHITE BACKGROUND, well you cant see the enpass icon anymore. in my opinion it would be to use either the normal enpass logo or add some borders to the current logo, although while we are at it it would be great to add a way to see whether the DB is locked or not in the tray icon.

well it would be great if you wouldnt always need to select the folder and just keep everything nicely contained in the enpass folder, could it be possible to make an option for that?

wait it locks enpass upon unlocking the screen? that sounds weird, I mean wouldnt it make more sense to lock upon locking the screen, especially because otherwise if someone else with admin access gets in he/she can read the ram and therefore enpass's database while it's unlocked.

but wouldnt it be possibly better to instead of using the cloudfront domains to your your own domains with a CNAME? especially cloudfront is a large thing which can have anything

and while you're at it, a DNSSec protection of the enpass domain wouldnt be bad to make sure that no junk happens (hacked enpass versions, DNS Servers etc)

On 10.9.2016 at 0:15 PM, ithinkiam said:

More and more websites only ask for individual characters from your password so it's not possible to autofill

you have some examples? because I never saw websites like that, and I REALLY think that these websites should be avoided because being able to ask for specific chars of the PW almost certainly means plaintext (or plaintext retrievable, e.g. plain encrypted) storage.

I can fully understand the decision because if a user would be able to choose the passwords he could try to change it all the time making the pro not needed anymore.

(honesty information: well I dont need to care about the passwords coz I got enpass pro for free a while ago: http://www.androidpolice.com/2016/01/12/deal-alert-get-enpass-password-managers-9-99-pro-license-for-free-today/ )

portable enpass isnt bad and I must say that I likt it but one option would be intresting:

an option to not store a db file on the medium and only use the cloud backup in the RAM.

this can be used for example that you can keep enpass on a read only medium which by definition cannot be compromised (okay you can screw updates but can still be great considering that there are usb viruses and whatnot which cannot get on the disc.

This obviously is meant only as an option but is in my opinion still better than lastpass and stuff because you choose where the DB lies.

On 13.9.2016 at 11:43 AM, Kristian said:

While it's currently 256 bit AES, I always like to go the extra mile and increase the standard value - probably 512 here.

I am pretty sure that AES cannot do 512 bit.

On 13.9.2016 at 2:52 PM, Xinamo said:

NIST guidelines recommend at least 10K of iretations. So I'm pretty sure the current 24K rounds is more than enough

I personally dont care about NIST.

and if the aliminuin hat fraction wants to increase the iteration so that it takes a whole minute for key calculation, why not let them is isnt as if this would affect you or is it?

On 13.9.2016 at 11:43 AM, Kristian said:

Please give us more options to increase the security by our own. I like the idea to have an "Expert Settings" tab.

I fully agree to this as long as the options arent complete snakeoil.

one thing that could be done would be having an option for scrypt which allows the user also to get more RAM usage for the key calculation which helps against parallelization.

On 13.9.2016 at 2:52 PM, Xinamo said:

Password with 8 letters + numbers + punctuation OR 4 random Diceware words would take 3250 years to crack if you use 10K rounds. So that's that

on what machine? I think having the choice of choosing stronger values for futureproofing would be great.