Auto sign out options

[Brian]

Actually Dale in respect of your comment “a screen saver is not sufficient to prevent someone with physical access to a drive from delete files, moving them, copying them etc” you’re wrong. A screensaver is sufficient to prevent someone with physical access for two reasons:

1. Windows includes device encryption, turned on by default, for all Home users. Business users get BitLocker. Both products prevent somebody with physical access circumventing the screensaver. Long gone are the days when you could boot into another OS with a CD/DVD/USB and access the home directory. Nor you can you remove the password from the user account from a system with device encryption.
2. Giving you the benefit of the doubt, i.e. assuming that device encryption was not in use, then having physical access to the device (assuming that a locked screensaver was in use) would not be sufficient to bypass AxCrypt because in order to do so you’d need to restart the computer or somehow log out of the current account. By doing either of the foregoing you’d destroy AxCrypt’s temporarily saved encryption key.

You’ve yet to give a feasible scenario where your suggested feature would make the user more secure. This isn’t being ‘sanctimonious’, it’s called being ‘pragmatic’. Of course you’re entitled to suggest features but I’m more interested in hearing your rationale.

I’ve only been working in various information security roles for 30 years so what do I know.

[SvanteSpectator]

Hey, Dale and Brian and everyone else!

This is your friendly lead developer of AxCrypt and sometimes moderator. We’d like to keep this a nice and helpful part of the Internet.

I think your discussion is definititely helpful and full of valid views and input from all sides, but sometimes frustration over not feeling one or the other getting the point across shows in the language used. I’m stepping in now, not because this thread has derailed, but to keep it from doing so.

Let’s all respect each others opinions, and we can all learn from a discussion like this.

I’ll refrain from adding any comments on the actual issue – I think I’ve expressed them earlier and elsewhere.

Just one thing on this kind of discussion; just because I or the team has expressed an opinion at one time or another, doesn’t mean we can’t change, tweak or even reverse our position on an issue. Which already has happened on this issue, to a large degree because of discussions like this one.

So, keep it coming from all sides, but let’s all stay nice people! We all have a common goal, to protect our information confidentiality and personal integrity in various ways, where AxCrypt is hopefully one piece of the puzzle.

Thanks all to contributing here! We want this to be a community where we all can learn and contribute, and we as the team behind AxCrypt want to keep adapting and improving AxCrypt as result of the discussions here.

[Peter]

Svante,

Thank you for your input.  I did not want to create a firestorm with this request, only to ask that a feature that led me to choose AxCrypt in ver. 1, be added back to ver. 2.  While I appreciate the viewpoint of Brian in his responses, Dale is absolutely correct in that how Dale sees the product used is not necessarily the way others use the product.  The added level of security that is established by having to use the password every time is obviously a desire from many who use this product have and that is why you have chosen to re-incorporate it in the near future.  I thank you for that.

[Dale]

Scenario:

I, user X:

1)  Want to add encryption security to certain files.

2)don’t want to (’cause it’s a pain in the arse, or for some practical reason can’t) use a lock screen.

3) know what this means. I also know the extent and limitations of the added security the requested functionality provides.

End result of user  described above with the option of using the requested functionality: Greater security.

Given the stated aims and  expertise of some the contributers here, Im not sure why Im the only one pointing this out here (reiterating even) but a screen saver password /screen lock is NOT in and of itself sufficient to stop someone with physical access to your drive from taking operating on data held on it.  It requires additional security measure such as (in the case of Windows ) EFS encryption of the files on the drive – a feature not turned on by default (or even supported) in some versions of windows:
http://www.infoworld.com/article/3036781/encryption/fbi-keep-out-how-to-encrypt-everything-windows-os-x-ios-android.html

[Brian]

Dale,

I suspect you’re the only one ‘pointing it out’ [about the screensaver] because you’re behind with the times. It’s simply not accurate to suggest that Windows isn’t encrypted – it is. This has been the default configuration since Windows 8.1 – full disk encryption.

Let me reiterate what I said earlier: if you have a lockable screensaver somebody cannot gain access to your files. No can do.

• If they restart the computer they need your password to login to your user account..
• If they remove the hard disk and put it into another system the data is useless (it’s encrypted).
• If they try and boot up into a live CD environment the data cannot be read (it’s encrypted).

Somebody with physical access cannot get at your data. (Forget about EFS; that’s old-hat and isn’t how Windows Device Encryption works. EFS is file-level, certificate based encryption which doesn’t encrypt the whole disk.)

The article you quoted is incomplete. It talks about BitLocker which as I said earlier is only available for Pro, Education or Enterprise users. Everybody else gets Device Encryption; you get fewer options but the net result is the same: full disk encryption. Here’s a more accurate article. All modern systems support Device Encryption since that article was written in 2013.

Here’s my original post:

“Windows includes device encryption, turned on by default, for all Home users. Business users get BitLocker. Both products prevent somebody with physical access circumventing the screensaver. Long gone are the days when you could boot into another OS with a CD/DVD/USB and access the home directory. Nor you can you remove the password from the user account from a system with device encryption.”

Apart from there being some undisclosed ‘practical reason’ for not locking your screen (in which case you’ve rendered AxCrypt and any other encryption product useless) the argument that locking your screen doesn’t protect you is fallacious for the reasons I’ve given above. It’s the best line of defence.

[Peter]

Brian,

you wrote “Apart from there being some undisclosed ‘practical reason’ for not locking your screen (in which case you’ve rendered AxCrypt and any other encryption product useless)”, and this is faulty for two reasons.  1) ver. 1 had this functionality so there was logic to have it, and 2) once again you are ignoring the inherent security that is given when every file requires the password to open.  Regardless if you lock the screen when you step away, whether it auto locks, whether your hard drive is stolen, laptop is stolen, or aliens use some incredibly advanced tech to crack the lockscreen/screensaver.  By requiring the password every time, the files can not be accidentally opened, regardless of the reason(s).  I do not know why you are so against the added level of security that ver. 1 had.

This back and forth is moot due to the fix that will soon allow every file to require a password to open, which is what the customers want.

[Brian]

One final point Dale is that AxCrypt automatically logs you out once the screensaver has been deactivated.

So even on a very old system without Device Encryption if somebody had physical access to the machine and restarted the system (to close down the screensaver) and reset the user account password (you can’t do that nowadays!) they still wouldn’t be able to access your AxCrypt files because AxCrypt would have destroyed the encryption keys from memory and you’d have to sign back in.

[Brian]

Dale, the reason it existed in 1.7 is because:

• computers didn’t use full disk encryption
• the encryption was asymmetric and AxCrypt worked differently

Actually you’re wrong when you say:

“By requiring the password every time, the files can not be accidentally opened, regardless of the reason(s).”

It still is possible to extract the AxCrypt encryption key from your system if you leave your screen unlocked.

“I do not know why you are so against the added level of security that ver. 1 had.”

Because some people will be lulled into a false sense of security and not take sensible precautions to protect themselves.

“This back and forth is moot due to the fix that will soon allow every file to require a password to open, which is what the customers want.”

If it ever gets added. Only a handful of people have asked for it from what I can gather and the lead developer has openly said it won’t increase your security in his post.

[Brian]

Also:

https://forum.axcrypt.net/blog/leaving-computer-axcrypt/

[Dale]

 

It’s simply not accurate to suggest that Windows isn’t encrypted – it is

Your posts now leave me seriously doubting as to whether or not you are trolling this thread Brian.

Is the above serious claim? Did you read the post you linked to?  The bit about hardware?  Do you have any idea the vast numbers of people who are right this moment running versions of Widows 7 versions alone which don’t have encryption of their data enabled? No encryption and thus no protection against someone with physical access to their drive, screen saver password or no screen saver password?

If you really do work in the field of data security,  then your inability to understand the usage scenarios explained here,  apparent lack of awareness over security issues, and your estimations of users such as Peter and myself (apparently as incapable of evaluating the implications of the features we have requested!) are quite astonishing. If that is the case I can only hope for the sake of your customers your contribtions here are part of some warped awareness raising exercise.

Developers, thanks for adding this functionality.

[Dale]

 

“It’s simply not accurate to suggest that Windows isn’t encrypted – it is”

Your posts now leave me seriously doubting as to whether or not you are trolling this thread Brian.

Is the above serious claim? Did you read the post you linked to?  The bit about hardware?  Do you have any idea the vast numbers of people who are right this moment running versions of Widows 7 versions alone which don’t have encryption of their data enabled? No encryption and thus no protection against someone with physical access to their drive, screen saver password or no screen saver password?

If you really do work in the field of data security,  then your inability to understand the usage scenarios explained here,  apparent lack of awareness over security issues, and your estimations of users such as Peter and myself (apparently as incapable of evaluating the implications of the features we have requested!) are quite astonishing. If that is the case I can only hope for the sake of your customers your contribtions here are part of some warped awareness raising exercise.

Developers, thanks for adding this functionality.

[Anonymous]

Dale,

I’m afraid to say that I think you’re trolling, not me, because of your inability or wilful refusal to comprehend my posts. There doesn’t seem to be a language barrier either.

You are criticising the lead developer (Svante) by suggesting that he can’t evaluate security when he has said the reason this hasn’t been added is because it doesn’t make you more secure.

You said, again entirely incorrectly,

Do you have any idea the vast numbers of people who are right this moment running versions of Widows 7 versions alone which don’t have encryption of their data enabled? No encryption and thus no protection against someone with physical access to their drive, screen saver password or no screen saver password?

I earlier said that this made no difference but you chose to ignore it:

 “So even on a very old system without Device Encryption if somebody had physical access to the machine and restarted the system (to close down the screensaver) and reset the user account password (you can’t do that nowadays!) they still wouldn’t be able to access your AxCrypt files because AxCrypt would have destroyed the encryption keys from memory and you’d have to sign back in.”

^ Simple explanation: Windows 7 users are still safe.

Dale, you personify the reason why it’s important to protect users from themselves.

You simply don’t have even a basic knowledge of encryption or system security, which is fine, but, you then try to belittle those who do (including the lead developer) by suggesting they don’t know what they’re talking about and failing to read answers to your questions.

If you’re going to ask questions please be respectful and you’ll find people more forthcoming.

[Brian]

My name was omitted from the above for some reason.

[SvanteSpectator]

Guys! Respect, please, or I’ll have to start moderate this. Please? Go for the issue, not the person.

The discussion is interesting, and I actually think all parties have something to learn here. But keep a nice tone, and stick to talking about the problem, not individual persons!

While the information is hard to really understand from Microsoft, here are are some facts about the term “device encryption”:

– It’s sometimes used as a generic term, i.e. “On Windows 8.1 Pro, device encryption can be done with BitLocker”.

– It’s sometimes used as a specific feature name, i.e. “Windows 8.1 RT includes Device Encryption (a stripped down version of BitLocker)”.

– BitLocker on desktop PC’s is not enabled by default. It can be in Enterprise environments for example.

– Device Encryption is enabled by default on certain devices, including mobile and desktop PC’s provided a number of critera are met, which includes a TPM that supports connected stand-by, it’s a clean install, the manufacturer has chosen not to disable it etc.

– Device Encryption, if supported and enabled, will not actually protect your data until you sign in with an online Microsoft Account or a domain account, with administrative privileges. Before then, the drives are encrypted, but the volume master key itself is not protected, making it available to anyone using the computer with a clear key. This is equivalent to BitLocker suspended state. After the administrative sign in, a recovery key is generated and uploaded to the Microsoft Account and the TPM is configured to not release the volume master key using the clear key. At this point, the drive is protected.

So, to sum up the findings on underlying hard drive encryption on Windows devices:

While many new tablets and PC’s will have it enabled and activated by default, it’s a good idea to check and verify since it’s so transparent you can’t really tell if it’s on or not unless you check.

It’s a good idea to ensure it is enabled, as it complements for example AxCrypt in many ways.

Thanks for providing incentive to write up this summary. It’s far from a clear-cut case, and available information is easy to misinterpret, to a large degree because of confusing naming practices by Microsoft.

[Dale]

(This post has been edited by a moderator since it contains personal references irrelevant to the issue at hand)

(redacted) Im going to repeat the information /claims I have posted here (redacted)

1) There exist PC users who a) need the ‘unlock each time’ security feature requested here b) dont want to or cant for some reason use a screen saver password, 3) Are savvy enough to understand the limitations and extent of the additional security this measure provides (that this does not provide the same type of security as a screen saver password, etc etc )and that in these users cases the ‘false sense of security leads to reduced security’ rationale (redacted), therefore does not apply.

2) An above described ‘savvy’ user  encrypting their files using Axcrypt (and, yes, not using a screen saver) has better security for this data than the same user not encypting their files (again, the user is not using a screen saver password).

3) A screen saver with password alone is not sufficient to prevent somebody with physical access to your hard drive from operating on or taking the data on your drive.  Additional security measures are required (Drive encryption, data encryptonn, drive locking, etc) ,

4) The security measures in 3. above are not activated by default in a number of operating systems. For users who’s operating systems are not running these additional measures,   someone with physical access to their drives can potentially operate on their data.

(redacted) which, if any, of the above are (redacted) false?

 

 

 

• This reply was modified 7 years, 10 months ago by  Svante. Reason: Irrelevant personal references

[Author]

Posts