Activity for tempik
-
tempik modified a comment on discussion Open Discussion
...with Excel you can imagine what is possible and what not... Never ending story 😃 I agree everything can be bypassed but for many people it is well known addins or scripts is the issue so policies, users or antiviruses blocks them. Not true with config manipulation in Keepass or any other apps. Maybe users can imagine there is plugin support in Keepass but minimum will know about export trigger. Yes it is fault on user side and that Keepass is not so publicly discussed. What I wanted to say is...
-
...with Excel you can imagine what is possible and what not... Never ending story 😃 I agree everything can be bypassed but for many people it is well known addins or scripts is the issue so policies, users or antiviruses blocks them. Not true with config manipulation in Keepass or any other apps. Maybe users can imagine there is plugin support in Keepass but minimum will know about export trigger. Yes it is fault on user side and that Keepass is not so publicly discussed. What I wanted to say is...
-
Mentioned it in my post before I spotted your response, agree with cloud based attacks vs. printed passwords but don't agree with Keepass vs encrypted excel. If I will be general admin in shared environment, with admins using Keepass and Excel. It seems now that it will be quite hard to export an encrypted xlsx vs. export Keepass db. And yes, it is mainly because these admins don't know such "hidden" feature exists, how easily it is possible to export their protected DBs. And yes, it is their fault...
-
Mentioned it in my post before I spotted your response, agree with cloud based attacks vs. printed passwords but don't agree with Keepass vs encrypted excel. If I will be general admin in shared environment, with admins using Keepass and Excel. It seems now that it will be quite hard to export an encrypted xlsx vs. export Keepass db. And yes, it is mainly because these admins don't know such "hidden" feature exists, how easily it is possible to export their protected DBs. And yes, it is their fault...
-
mentioned in my post, agree with cloud based attacks vs. printed passwords but don't agree with Keepass vs encrypted excel. If I will be general admin in shared environment, with admins using Keepass and Excel. It seems now that it will be quite hard to export an encrypted xlsx vs. export Keepass db. And yes, it is mainly because these admins don't know such "hidden" feature exists, how easily it is possible to export their protected DBs. And yes, it is their fault but it is the best practice to...
-
Do you want to say that all password managers are useless, so recommending an encrypted xlsx Excel file which is much more robust? It is silly but it is like that. You need much more skills to open encrypted db with help of user and automatically export it, without stealing his session, highjack processes, etc... Definitely better to use e.g. mentioned excel sheet than hand written pwd pinned to the monitor 😏 but you are true, for cloud based attacks, definitely hands written passwords is a win ...
-
But it is also true your passwords are safe like protection of your config file. If your PC is clean, no other admins/users, you are on a safe side. But honestly in such cases you will be safe with unencrypted txt file as well😏 It is not the question how hard is it to gain such access to it but that it is possible and users don't know it so in most cases they don't protect config file and antivirus does the same...
-
But it is also true your passwords are safe like protection of your config file. If your PC is clean, no other admins/users, you are on a safe side. But honestly in such cases you will be safe with unencrypted txt file as well😏 It is not the question how hard is it to gain such access to it but that it is possible and users don't know it so in most cases they don't protect config file, antivirus does same...
-
But it is also true your passwords are safe like protection of your config file. If your PC is clean, no other admins/users, you are on a safe side. But honestly in such cases you will be safe with unencrypted txt file as well😏 It is not the question how hard is it to gain such access to it but that it is possible and users don't know it so in most cases don't protect config file, antivirus does same...
-
Do you want to say that all password managers are useless, so recommending an encrypted xlsx Excel file which is much more robust? It is silly but it is like that. You need much more skills to open encrypted db with help of user and automatically export it, without stealing his session, highjack processes, etc... Definitely better to use e.g. mentioned excel sheet than hand written pwd pinned to the monitor 😏
-
Do you want to say that all password managers are useless, so recommending encrypted xlsx Excel fine which is much more robust? It is silly but it is like that. You need much more skills to open encrypted db with help of user and automatically export it, without stealing his session, highjack processes, etc... Definitely better to use e.g. mentioned excel sheet than hand written pwd pinned to the monitor 😏
-
https://sourceforge.net/p/keepass/discussion/329220/thread/a146e5cf6b/?page=4#3019 for some idea... There is no option to protect your DB easily without some major design change in keepass kdbx+app. In short: Whatever technique you will use to protect DB, once you will write password (use Yubikey, smartcard), your DB can be exported silently in clear text. No need to know your password, using keyloggers etc, only the write access to the xml file is enough and time...
-
https://sourceforge.net/p/keepass/discussion/329220/thread/a146e5cf6b/?page=4#3019 There is no option to protect your DB easily without some major design change in keepass kdbx+app. In short: Whatever technique you will use to protect DB, once you will write password (use Yubikey, smartcard), your DB can be exported silently in clear text. No need to know your password, using keyloggers etc, only the write access to the xml file is enough and time...
-
A lot of users are using their portable KeePass from the USB stick, with exFat or Fat32 so there is no ACL/ownership in place. It means anyone, admin or unprivileged user have access to the xml or binary. Attack vector via xml can use 99% of "attackers" but rebuilding binaries, dlls, certificates can do fraction of them. The basic "solution" to e.g. require master password during decryption with new KeePass version or extending kdbx format to be e.g. non-exportable will filter another portion of...
-
A lot of users are using their portable KeePass from the USB stick, with exFat or Fat32 so there is no ACL/ownership in place. It means anyone, admin or unprivileged user have access to the xml or binary. Attack vector via xml can use 99% of "attackers" but rebuilding binaries, dlls, certificates can do fraction of them. The basic "solution" to e.g. require master password during decryption with new KeePass version or extending kdbx format to be e.g. non-exportable will filter another portion of...
-
A lot of users are using their portable KeePass from the USB stick, with exFat or Fat so there is no ACL/ownership in place. It means anyone, admin or unprivileged user have access to the xml or binary. Attack vector via xml can use 99% of "attackers" but rebuilding binaries, dlls, certificates can do fraction of them. The basic "solution" to e.g. require master password during decryption with new KeePass version or extending kdbx format to be e.g. non-exportable will filter another portion of them...
-
Not all corporate admins lock users running the approved apps only. You don't need admin access to the computer, you can use portable KeePass locally or from USB stick and it is widely used scenario. The main issue is the user is kept unaware that there is such a risk, easy path how to get unencrypted DB, without any hacking skills and this is the main problem. It seems to me general use case is KeePass usage on unprotected, foreign PC,etc... Nobody is talking about the option to replace .exe with...
-
Current design seems to me like super trooper encryption used to protect XLSX file,e.g. via user password but with the unprotected option in Excel app to decrypt file automatically upon loading the file and storing it in cleartext to disk, silently. You can't decrypt DB or make a memory dump but why doing it when it is enough to say Excel to decrypt and save it automatically, silently? As a guy working in IT security no one will convince me that this is the correct design for the application behavior....
-
You don't understand what I tried to say. If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain. Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently? I am sure there are majority of users they don't know it can't be used on shared...
-
You don't understand what I tried to say. If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain. Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently? I am sure there are majority of users they don't know it can't be used on shared...
-
You don't understand what I tried to say. If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain. Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently? I am sure there are majority of users they don't know it can't be used on shared...
-
You don't understand what I tried to say. If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain. Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently? I am sure there are majority of users they don't know it can't be used on shared...
-
You don't understand what I tried to say. If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain. Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently? I am sure there are majority of users they don't know it can't be used on shared...
-
You don't understand what I tried to say. If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain. Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently? I am sure there are majority of users they don't know it can't be used on shared...
-
The main issue is that KeePass tries to evoke in users it is very secure but it is not. Why implementing memory protection etc. when protected DB can be easily exported in cleartext without user intervention? I am not talking about hacked PC, imagine shared computer, where all users are admins. By trivial modification another user can, without noticing, export passwords from protected DB of different user! For general user, they can't imagine such easy method of attack vector on their protected DB!...
-
VOTE: unimediaserver
-
Thanks for "ParseSpeed" tip! Much appreciated.
-
Thanks for info Jerome. So similar I can use for DLL and its API to change FileTestContinuousFileNames=false....
-
Thanks for info Jerome. So similar I can use for DLL and its API to change FileTestContinuousFileNames=false....
-
Ok, seems it is not bug but new feature. So the question is how to disable it for...
-
Ok, seems it is not bug but new feature. So question is how to disable it for speed...
-
Ok, seems it is not bug but new feature. So question is how to disable it for speed...
-
Wrong Bitrate returned if more than 23 files exist in same folder with similar naming convention
1