[SvanteSpectator]

Hello tumlatum,

Since I don’t know your account email, I can’t know if you ‘changed’ password or ‘reset’ password. However, regardless, the file will *always* open with the password that was in effect when it was originally encrypted.

So, if you can sign in to AxCrypt, and can’t open the file you should be presented with a file password dialog. The password to enter here is the one that was in effect on the day that you last encrypted the file.

Once you’re signed in to AxCrypt, you can try the file password for as many times you want. Signing in to AxCrypt (online) does limit the number of tries to 15, then you have to wait for an hour.

If you wish further clarification, please add some screen shots of where you’re stuck – this usually helps to clarify things for us a lot!

[SvanteSpectator]

Hello Al,

It’s so hard to make everyone happy, and not destroy the app with a zillion options ;-)

Most users are concerned about *not* having to enter the password every time…

We’re thinking about a way to enable some of these optional behaviors in a way that does not negatively impact the clear majority of users who’re really happy with the way we designed it.

I essentially agree with you – if you’re actually behind a password protected screen saver, there’s a good case for keeping you signed in. But most users see it differently, so we implemented the auto-sign out.

Stay tuned, we’ll be working with these issues the coming weeks.

[SvanteSpectator]

Hello Tony!

Thanks for your input! We’re certainly listening to the views of our existing users, and we’re working hard trying to find a golden middle path. Who knows – maybe we’ll relaunch as AxCrypt Classic and skip New AxCrypt ;-) Ok, that probably won’t happen, but we may indeed support something similar to “Classic Mode”.

We’ve just had a product meeting discussing these issues, and we’ll be working in the coming weeks to try to meet many of you at least half-way.

The thing about the free AxCrypt 1.x, which I’m indeed proud of, is that I simply cannot maintain it for nothing and unfortunately very few of the existing users donated. If just a few percent of the users had… But that didn’t and won’t happen. Just the way things are. So, while many like yourself say that you’d gladly pay for a version like the 1.7, the real world seems to be different. There’s just not enough of you to support the development.

So… What we’re hoping is that users like yourself realize that you’ll have to give us *something* to get a software such as AxCrypt. That’s essentially the ‘first time signup’. You’re giving us your e-mail, which is no secret, and which does enable you to *receive* encrypted information, even if you, yourself, never have the impulse to share. Someone else may want to share with you. If you’re registered, you’re already in our catalog of users and it’s easier to share with you. It’s a small, but definitive value to us as a product, and a value to our paying users who for whatever reason do want to share. Please note also that version 2 does not have any kind of advertising wrapper, and there’s no advertising on the site either. All we’re asking for is your email, and we promise to do nothing bad with it (not that there’s much bad that can be done that’s not already done with most email-addresses).

Is that really too high a price to pay? Letting us know your email? Something every spammer on earth, everyone you ever sent an email to, and every web site you ever registered with already knows?

Also, Internet is not required. You can disable Internet access ‘permanently’, either with a command line switch –offline, or via the menus. In this case we won’t even get your email :-( .

Our aim is to retain as much as possible like the existing version for free, while creating enough clear value with additional features and platform support (iOS and Android coming up) to get enough paying users to finance the continued development. This all will benefit from.

Now, I’ll go back to working with the various issues we’ve logged as a result of input from existing users like yourself! Thank you! See https://bitbucket.org/axantum/axcrypt-net/issues?status=new&status=open to follow progress!

[SvanteSpectator]

Hello Ritu,

Understood. When you are up for it, or experience similar problems with another application you should also try to repair the .NET framework. It has helped in a few similar situations.

[SvanteSpectator]

Hello Gene,

There seems to be some misunderstandings here.

What we’re storing is an encrypted copy of your sharing key. This is not the same as your password. It is another piece of data, encrypted with your password using AxCrypt. The whole point of AxCrypt is that files encrypted with AxCrypt should be able to be public. While we have no intention of making your encrypted secret sharing key public, the point is that even it that should happen it should not compromise your data. Since for that to be an issue, someone must have access to one of your encrypted files, so getting another won’t help.

I do not understand what you refer to when you say: “The keys and my computers GUIDs are stored there also“. We do not store anything like that.

No login or Internet connection is required either, if you don’t enable Internet access or can’t or won’t reach our servers AxCrypt will still work fine. The sharing functionality won’t work fully as well as some other Premium functions, but you’ll always be able to open, work with and encrypt files.

[SvanteSpectator]

Hello Stijn,

This sounds more than strange… Although of course a Windows update can affect how software works, that it would affect AxCrypt in such way that it all works but not the password is very unlikely to say the least.

So, I think something else is going on here.

Can you please post a screen shot of the screen when it says the password is wrong, and one from a successful sign in?

Svante

[SvanteSpectator]

Hello LA,

Thanks for letting us know. Normally ‘open in another application’ is just a supposedly user-friendly way of saying ‘the file is locked by another process’, and it would indeed normally stop rename/delete etc. However, in this case, rename/delete etc is done by the Windows Explorer process so it’s locked by itself and can thus handle the situation – I’m guessing.

I’ll see if I can reproduce this, and see if there’s some way to handle it better.

Svante

[SvanteSpectator]

Hello.

Ensure for example Acrobat is closed.

You can also find out what process is locking the file. Google for example

File is locked by another process

There are many ways.

Svante

[SvanteSpectator]

Can you try to start AxCrypt in Offline mode, do this by starting with:

%ProgramFiles%\AxCrypt\AxCrypt\AxCrypt.exe –offline

[SvanteSpectator]

Hello,

It seems to be something with network access that fails. Are you behind a web proxy or using a VPN?

You might also try to start AxCrypt with the –offline switch. Run a command like the following:

%ProgramFiles%\AxCrypt\AxCrypt\AxCrypt.exe –offline

This will disable all network access (permanently, until you re-enable it from the menus).

It would be good if you could check the Event Viewer also for any more events related to this. It’s something that is wrong with your PC environment, at least to the extent that the AxCrypt code does not handle it properly. The stack trace you showed, if it is relevant to the problem, does indicate that the exception is handled though, so it’s a bit unclear.

Thank you for working with us to resolve this.

Svante

[SvanteSpectator]

Hello and thank you.

It’s really hard to tell, but searching the internet finds a few similar situations where either a web proxy or VPN is involved. Does your computer connect directly to Internet, or via a Web Proxy or VPN?

Svante

[SvanteSpectator]

Hello Jason,

Thanks for your input!

Well, no, files are not automatically decrypted when you log in to Windows. However, if you are sharing a PC with a single account, then it’s simply not a very suitable environment to keep any kind of secrets.

Is it really a requirement to share the same account? It’s such a bad idea in so many ways…

Also, using different passwords for different files is seldom an optimal strategy. I wrote a blog post that discusses this, http://www.axcrypt.net/blog/use-of-different-passwords/ .

Regards,

Svante

[SvanteSpectator]

Hello Robert,

This is essentially correct. AxCrypt 1 disallows many such characters. If you look carefully when you enter the password in v1 you’ll see it is in fact not accepted. There should even be a ‘beep’.

We’ll change it so v2 will try v1 files with v1 illegal chars filtered out as well.

Svante

[SvanteSpectator]

Hello Greg,

We’re likely to implement recursion along with some other advanced options to cater to differing needs.

Recursion as such is almost trivial, it’s the user interface to view and enable disable that’s the challenge.

We will likely collect all ‘dangerous’ nonstandard options into a single dialog and then require password verification to change.

Svante

[SvanteSpectator]

Tahnk you, unfortunately it did not help, since only old exceptions were there.

What version of AxCrypt are you running?

Just how far do you get? Do you get to sign in?

[Author]

Posts