Forum Replies Created
-
AuthorPosts
-
Hello Rob,
I’m afraid you lost me a little bit. What’s the point of encryption if there is no secret key involved somewhere?
AxCrypt almost does what you say, you can share the embedded file key with anyone with an email address, and they can sign in using their own password. But they still need to enter and know that password.
others, from earlier versions of the program are filetype “xls”
That used to be true with Microsoft Office versions 2007 and below.
The file was of type .xls, which is an older format, and that was the format *before* Office 2007.
Hello Old Bob,
This means that the Excel-file itself is password protected by Excel. This has nothing to do with AxCrypt. Google the error message, and the top hit is: https://support.microsoft.com/en-in/help/321147/error-message-the-password-you-supplied-is-not-correct .
Apparently, you have both password-protected the Excel file and also then encrypted it with AxCrypt. You’ll have to remember the Excel password – or get a cracker. Contrary to AxCrypt, Excel password protection can usually be cracked ;-)
Hello Gary,
AxCrypt 2 asks you to sign in to your account, which AxCrypt 1 did not. We now use a single sign on model where the same password is used to sign in to our servers and to protect your files. The password that you’re being asked for is the password to your account, which you probably created when you first installed AxCrypt 1.
If you do not remember the password to your account, you can always reset it. This is not a way to recover encrypted files! It’s only to allow you to sign in to the AxCrypt app and web. The new password will be used to encrypt new files. Go to https://account.axcrypt.net/Home/PasswordReset to do this, or you can also go there from AxCrypt with File | Options | Password Reset .
If you open files encrypted with a different password than your sign in password, which often is the case directly after upgrading to version 2, you will be prompted for that original password. If the file was encrypted with version 1, it will then be automatically upgraded to version 2 and to use the new sign in password which means you won’t be prompted again for the old password.
Helllo jsampson45,
Yes, the “Save As” question is relevant.
It’s on the to-do list, or at least to-investigate list, see:
https://bitbucket.org/axantum/axcrypt-net/issues/139/set-working-directory-to-original
https://bitbucket.org/axantum/axcrypt-net/issues/92/encrypt-extra-files-in-the-work-folder
Thank you Iain!
Hello Jorge,
I have no idea of the quality of the estimation of your password manager, but 32 characters is indeed very long. If it’s not a simple phrase in english or based on some other system that once known by an attacker reduces the search space, it’s a very strong password. With or without extra iterations.
So, yes, that will thwart any realistic attack.
Hello Dean,
Start by clicking “Save”. This reduces the complexity a bit. Save it in “My Documents” or a similar place.
Now you have a file in the file system, and you can try to open it with double-click, or more appropriately, right-click it and select AxCrypt | Decrypt. I don’t think Turbotax actually opens files by double-clicking, so you may have to import it or otherwise get it “into” Turbotax.
Hello,
When was this last opened, and when was it originally encrypted (or, more precisely, with what version of AxCrypt)?
Hello Jorge,
We don’t focus on length, but on complexity. That said – at least 10 characters, digits and symbols.
The second question can’t be answered in a precise way. AxCrypt uses a dynamic number of iterations to strengthen the effective password length with 12-14 bits (very approximately and it depends on the encrypting computer). The speed of the “super computer” is affected by the amount of money spent on it.
The better questions are:
1) What is the effective length of your password? Our password manager generates strong passwords at around 90 bits.
2) How many bits effective key length / second do you think the presumed attacker has a budget for?
Hello Steve,
If you look a little further down on the pricing page, you’ll find the following text:
“All pricing excl. VAT which will be applied for EU customers according to EU rules on order. We do not support VAT-free sales to VAT-registered companies within the EU. To start using AxCrypt you have to sign up for an account. A 30 day trial of AxCrypt Premium is included and will start when you activate your account.”
So there’s nothing wrong with the pricing, it’s just that you need to pay VAT on top of the €24.
Hello Dwight,
You write “I prefer the V1 approach which allows for different local passwords“. I may have mentioned before in this thread, but I wrote a longer essay on this here: https://forum.axcrypt.net/blog/use-of-different-passwords/ . I really think you should reconsider when you say “I want my different client files to have unique passwords“, but of course in the end – you decide! I can only advise. We’ll of course adapt to user demands, as long as it is not detrimental to overall security. We may indeed implement password based key sharing, if we can figure out a way to make it easy to use.
Hello kz,
Re “dokan”, well actually it does require tinkering with system files, very much so. It’s a kernel mode driver implementing a user mode file system on Windows. That’s what I mean with tight integration with Windows. While it does offer many advantages, we don’t want to go down that road for a number of other reasons. For example, it’s not possible to make a non-privileged portable desktop app since it requires installation of a kernel mode driver. This means it can’t be run or installed on a computer without permanently modifying the operating system and it requires administrative permissions. AxCrypt can run as a pure portable standalone without installing anything. Also, although it’s fairly mature, it’s scary to install a kernel mode driver and be responsible for that and there’s also a big risk with incompatibility with future versions of Windows. It requires something entirely different to work on the Mac and/or Linux, so maintenance and development costs goes up. These are just some of the reasons why we’ve decided to not do it like that.
A more likely scenario for us is indeed to implement a folder mirror, where we work as normal, and just copy / delete files between them as they appear and disappear – but only encrypted files to the secure folder, not plaintext files. There are some UX challenges with that, but we’ll see.
Thanks for the input!
Hello Dean!
You should have received a confirmation of the payment through our payment processor, Stripe in this case. We have received your payment, and your Premium subscription is active.
You write “Can anyone help me get back into my files?“. Premium is *never* required to open your files on your computer. We will *never* lock anyone out of their data due to lack of payment, that’d make AxCrypt ransomware which it’s not of course.
It’s not entirely clear exactly where you are stuck. Please provide more information about your problem, If you can send a screenshot showing where the problem is, it often helps us understand.
How to take a screenshot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .
If you do not want to post screenshots here, submit a Premium support request by signing in to https://forum.axcrypt.net/ or by sending an email to support att axcrypt dott net .
Hello kz!
Thank you ;-)
You make a very valid point about the sync folder issue with cloud storage providers. I’m not sure how Boxcryptor et. al. handles this case, but I believe they integrate very differently and more tightly with the host operating system, working as file system filters and similar. We integrate very loosely, which gives us many other advantages, but this can be an issue if you *really* don’t want any plaintext to hit the cloud ever.
I should mention though that it’s not quite like you say. The problem is not opening and working with encrypted files in a cloud service sync folder. The problem is when you drop new unencrypted files in such a folder, until you tell AxCrypt to encrypt them. Working on encrypted files is not a problem (as long as you don’t actually use AxCrypt | Decrypt). Working with files through double-click is safe in this scenario too.
We can probably never, with the current level of operating system integration, guarantee that no files ever hit the cloud since it essentially means we have to interfere quite harshly with the cloud service sync software. It must either never see the real file system, or we must be able to tell it to stop syncing or forbid it to sync files as they appear while they are unencrypted.
We’re certainly aiming at improving this, and many other things!
-
AuthorPosts