Forum Replies Created
-
AuthorPosts
-
In order to provide us with detailed information to help us help you, for this situation we’d like a full error report. Please follow the detailed instructions here: http://www.axcrypt.net/blog/send-complete-error-report/ .
Please send this to support att axcrypt dott net .
Hello Geoffrey,
From our logs we can see that you first set the password, then changed the password twice and then reset it on April 7. On April 23, you once again issued a password reset. Then, the next day on April 24 again a password reset.
It’s not entirely clear what stage you did the re-encryption mentioned, but there are no less than 6 different passwords used during three sessions that we can see. We don’t see much, but password changes and resets while online we do see (but not what the passwords are). This is exactly why we do log this – so we can help identify just what has happened!
So, what has happened is that you encrypted the files with one password, then issued at least one password reset after that.
You’ll have to think back on what passwords you used on these occasions, and one of those is the password requested by AxCrypt.
Hello Barry,
Thank you for reporting this. We are not aware of any issue with the brute force software and certainly not based on file size. If you have some sample file you can share with us, please contact support and we’ll look into it.
Hello SF,
Since you also sent an email, I’ve responded there as well. Please decide which channel you prefer, we can’t do both.
This is how AxCrypt works, it decrypts the files temporarily to that location, and keeps them there until it’s safe to remove them. If you delete them manually, that may cause problems.
If you have files there, and the ‘broom’ icon is not red and active, please let us know.
Hello Kent,
I see you switched to the Premium support channel, which I was going to suggest anyway. So we’ll respond there.
Hello Edward,
Right, now I understand. The dialog is there because the file password is *not* the same as your sign in password. The tooltip is there to help you realize that it does not make sense to enter the sign in password again, because the whole reason for the file password dialog is that the sign in password does not work.
I’d certainly ask if you wife has opened and modified the file recently, since that will re-encrypt the file with her password. To share a file like that, that’s what we have the key-sharing feature for. Setup up the file to be shared with both of you, and all should work without problems.
Hello Kent (and everyone else helping out here),
It really is very simple. The confusion here is about regular account management, and it’s nothing specific about AxCrypt. It’s how all account systems work.
An account always has some kind of identifier naming it. Sometimes it’s your realy name, sometimes it may be your phone number – but the absolutely most common account name identifier is an email address. AxCrypt accounts use the email address.
This type of system typically also relies on access to the mailbox associated with the email address as ‘proof of ownership’. That’s why we and everyone else sends out these emails with a verification link. The link contains something unique, that when used ‘proves’ to the server that you actually have access to the mailbox associated with the email address.
So, if I go ot a site, and enter *your* email address (let’s say bob@axcrypt.local), the account is created and an email is sent to *you*. I will never see it. You will see it, and hopefully just throw it away.
Or, you go to the site, register with your email (still bob@axcrypt.local in this alternate example), get the verification email, click on the link – use it a little bit, and then forget about it. Years passes…
Now, you are at the site again, you register with a different email (let’s say david@axcrypt.local), get the verification email and complete the process. Then you realize that you’d after like to use bob@axcrypt.local after all. So, you ask the site to change from ‘david@axcrypt.local’ -> ‘bob@axcrypt.local’.
But, ‘bob@axcrypt.local’ already exists on the server! The server has no real way of knowing that ‘david@axcrypt.local’ and ‘bob@axcrypt.local’ are really the same entity. So, it tells you “Sorry, but that account is already taken”.
What to do?
Simple – since you are in affect both, just sign in to ‘bob@axcrypt.local’ (if necessary reset the password, which you can do since you have access to the mail box), and then delete the account ‘bob@axcrypt.local’.
Now, you can go back to ‘david@axcrypt.local’, and change the email to ‘bob@axcrypt.local’ which is no longer existing, and thus the server allows the change.
The above procedure may differ in detail depending on the provider, but the core issue remains the same. In order to create, or move an account, you need to prove ownership of the account email. In the case of the change scenario, to both.
Thank you Jose!
Hello Edward,
It would really help with a screen shot, so we can see exactly where you are stuck. Also, you write that you get a message to the effect of “I have already used this password and to enter the password for the file” – this confuses me because try as I might I can’t recall AxCrypt actually has such a message.
Hello TC,
Thank you for reporting this. I think this is because you have:
1) Signed in to the Windows app.
2) Signed in to the web.
3) Changed the password via the web.
4) Gone back to the Windows app and you are now trying to do the invite – but the app has remembered the wrong password, which causes the invitation to fail with a bad error message.
The correct behavior here would be for the Windows to realize it is no longer correctly signed in, and sign out.
Please try to sign out of the Windows app and sign in again, and retry. If you can confirm if this works or not, we’ll then make a bug report about it.
Hello Darmar,
Thanks for your input – noted.
Hi Rob,
“if I have 5 users with a shared network drive which is designated as encrypted, would each of the 5 users have to have a paid account, or would just the one that initiates the share within AxCrypt?”
It depends on your scenario.
You need the Premium plan for two things in this context.
1) Designate a folder as “Secured”, which means that it is is monitored for changes, and you can set a default set of recipients for new files in the folder. So, when new files are discovered in the folder you can encrypt them with that set of recipients with a single click.
2) To add recipients to specific files, outside of “Secured Folders”. This can be done for ad-hoc specific files, but might be less important for your use-case.
A user does not need to be on the Premium plan in order to open, work with, and save a file that has been key shared. If a file that has say for example 5 recipients for the key share is edited and saved by a non-Premium user, that same set of 5 recipients can still open and work with the file.
So, if you have one user who “owns” the folder, adds files and determines who shold be able to read and update files, only that user needs Premium.
Premium is needed in order to designated folders as secured, and to add/remove recipients for secured folders and discrete files. To work with such files, the Free plan is sufficient.
Hello,
There is no need to worry about key import / export. It’s all done automatically by AxCrypt via our key distribution server. All you need to do and know is the recipient(s) email-addresses (only used to identify the recipient account, not to actually email any data).
The key sharing function embeds the shared key into the file. The file must thus first be key shared with the recipient, then sent or file shared. Please note that AxCrypt does not share or send the actual file. To see a quick instructional video explaining how to use key sharing, please view https://www.youtube.com/watch?v=9z3KOZD-Yks .
Please check out our video tutorials at https://www.youtube.com/channel/UCoSoXBjq6iCG5232fHoWStA and our other documentation at https://forum.axcrypt.net/documentation/get-started/ to get started with AxCrypt.
Once again, thanks Franz!
Thanks Franz,
Last(?) question…
From what you’re saying (and what I gleaned from the cursory glance at the office spec for cryptography and XLS), and from the screens above, it seems like the default behavior for saving a .XLS file even in modern versions of Excel is compatible with Excel 97 – 2003 which would imply that such a save has the weaknesses these versions of Excel has.
So, assuming a non-expert non-cryptography-setting-tweaking user, it’s still a fairly safe assumption that a .XLS file if password protected is protected with the old weak form of Office crypto – right?
If the file is saved in .XSLX-format, it’s also a fair assumption to make that it is saved as AES-128, once again assuming the non-tweaking user. So your last statement “For most users saving in the latest versions of Excel, with a secure password, they have no fear about the security unlike in olden times of Office. The default option is suitably secure even as AES128, 100,000 iterations at SHA1.” is valid when the file is saved as .XLSX in a newer version of Excel.
-
AuthorPosts