Forums Community AxCrypt 2.0 and 1.7 Reply To: AxCrypt 2.0 and 1.7

#3488 Reply

Svante
Spectator

Hello Andy!

Thanks for the feedback, it’s really appreciated.

First things first – I’m not accepting donations for AxCrypt via the new site, since we’re actually trying to run this as a Freemium software, i.e. a free software with a Premium mode for pay. So, sad to say perhaps, I’ve gone commercial. But, the intention is that the free functionality shall be fairly equivalent with the original free ‘donationware’.

That the donation button does not work on the old site is news to me, thanks for that. You’re right, the Payson link is dead. Will fix asap.

By the way, you do not need a PayPal account to use a credit card via PayPal, they’ll work as general payment provider also.

Now, as for the sign in & password issue. Technically there’s not really a problem having a separation of the password used to sign in to the web-part and do the things that the web is needed for. In fact, the software does support this partially, just try to open a file encrypted with version 1 and a different password and you’ll be prompted for it. But you can’t encrypt with a different password in AxCrypt 2 in any convenient way.

The reason we decided, so far anyway, to use a single password for it all is because we think that for most users the convenience outweighs the security concerns. I’m really not that keen on having users having to keep track of, and keep separate in their minds, two passwords. We have enough passwords to keep track of as it is!

Another reason to use a single password is that we’ve seen many cases with AxCrypt 1 where users encrypt a new file, and then either forget what password was used that time, or mistype it twice. Both cases lead to data loss. That’s another reason why we validate the password first, and only allow encryption after ‘signing in’. This decreases the risk of encrypting with the wrong password.

What we are considering for the future is a mode of operation where the password as such actually never reaches the server, instead we’d use a challenge-response protocol for the authentication part of the process, and to all encryption and decryption locally.

This should address your real concerns. The problem is that it might not be enough, because there’s an intuitive feeling that if a password is used for anything online, it’s a problem. Even when it’s really not.

What’s your take on this?

Svante