discussion how the fuck do you lock a porn folder on your computer?

[Anon7483]

oh my fucking god

Just stop it, man. I explicitly installed a virtual machine as a sanity check to make sure everything I'm saying is true, BEFORE I made that post. It is. No, an administrator CANNOT access EFS files just by changing your password. I literally tried it. It doesn't work.

If your argument for VeraCrypt not being FDE is seriously that it isn't actually FDE because EFI partitions exist, then congratulations. I've got no words for you. Same thing regarding the belief that "cryptanalysts" can "close to trivially" defeat modern ciphers via KPA. Guess you shouldn't install an operating system since it has a lot of "well-known files" as well. Embarrassing.

To clarify, UAC is sandboxing. It's built-in. Also, Windows Sandbox exists.

Plausible deniability is how you prevent a death sentence in dogshit countries, NOT encryption alone, because either:

1. You are, by law, compelled to disclose your encryption keys, OR
2. Encryption is illegal.

OpenBSD is Secure by Default :^)

No comment on the differences.

This is painful. Why are you like this?

 

[wibble]

Personally I have everything on a 2nd HDD. Use Bitlocker disk encryption on the whole drive. Don't forget also if someone has access to your PC, setup user accounts, then restrict file/folder access to only your ID. Once Bitlocker is unlocked it remains unlocked for all users until windows is restarted. So if your guest has an account on your PC after you have used it, they would have access to the drive unless you setup security for the folders/data. This also all needs Windows Pro, not Home.

File/folder security alone doesn't protect anything strongly becuase you can just attach/mount the drive in another PC and override the security parameters.

 

[trishit]

you can hide the folder whenever youre not using it, thats what i do

 

[Wisblade]

Just stop it, man. I explicitly installed a virtual machine as a sanity check to make sure everything I'm saying is true, BEFORE I made that post. It is. No, an administrator CANNOT access EFS files just by changing your password. I literally tried it. It doesn't work.

You're not scheming enough, as I was saying... I thought I had given a sufficient clue, but apparently, you took everything literally, foolishly.

• Offline (i.e. without the targeted OS running), backup SAM and SECURITY data.
• Change user's password from standard interface.
  • You're warned that user will lose all access to his encrypted files.
  • I think that it's better / safer to use "net user" command to do that, to avoid possible side-effects and/or certificates deletion.
• Log into user's account with new password.
• Install whatever you need on his session: keylogger, spyware, etc. since you can do everything - either with his account or with administrator's account and UAC prompts.
  • This can be as dumb as copying the files (they will be decrypted if done properly) to a "hidden" place, using a proper tool that doesn't do raw copy, and it's even better if the tool has a bandwidth limitation and a "suicide exit".
  • Such a copier should even be launched with SYSTEM privileges, and through "RunDLL" to be near invisible.
  • A really machiavellian one would overwrite dummy files with the same size created for this occasion, so that user's won't even see a free disk space change. Software would jump across cores to hide its CPU usage - basic behavior is to use only idle time to really do copies, of course...
• Log out, put OS offline again and restore SAM and SECURITY data - this will restore his password, but whatever you installed is still there.
• Wait for his login and then his data.

It can even work on the only admin account, since you need to boot a live OS to put the targeted OS offline - Windows is a bit trickier than Linux for this, it isn't enough to backup "/etc/passwd" here.

BTW, you can check: change the test account's password forcefully, log in - OK, encrypted files aren't available. Now, go back to your admin session, change again the password to the original one and log again the test account: miracle, encrypted files are accessible again!

Another thing, but I never investigated this part, is something about EFS (the encryption layer in NTFS) :

"Also, in case of a user losing access to their key, support for additional decryption keys has been built into the EFS system, so that a recovery agent can still access the files if needed."​

This only sentence is enough for me to consider EFS as not secured enough in anything but a (near) trusted environment. It's way enough to encrypt "private" or restricted files (like a business proposal) at work. It's just a joke for "Confidential Defense", "Secret Defense", or illegal data.

And, AGAIN, FDE doesn't have these flaws...

If your argument for VeraCrypt not being FDE is seriously that it isn't actually FDE because EFI partitions exist, then congratulations. I've got no words for you. Same thing regarding the belief that "cryptanalysts" can "close to trivially" defeat modern ciphers via KPA. Guess you shouldn't install an operating system since it has a lot of "well-known files" as well. Embarrassing.

You really don't understand anything... A real FDE doesn't leave ANY sector unencrypted, and a good one will even shuffle the sectors numbering so you won't even know where the "Sector #0" is located. An excellent one will also require a 2FA token to unlock the disk.

You don't understand shit about what is possible on an analyze machine, I even think that you believe that they are standard PC - at work, they are simple boards with a shitload of various connectors, custom FPGA & ASIC, etc. with another shitload of spy buses. You can plug anything on it, get a vampire connection on anything, get an interception connection on anything, and trigger any bus from any other bus event. We have guys at work able to make an UEFI bootloader, and to build custom Linux kernels and distros, or custom Windows - both being executed on encrypted hardware. Obviously, we also have tools to investigate such hardware when a problem occurs... And we are "only" a medium-sized enterprise, with poor capabilities compared to a governmental agency.

And for "well-know" files, you do realize that you can't find them on a fully encrypted disk? So you don't have the encrypted version to start any cryptanalyze? But it's VERY different if you're dumb enough to NTFS-encrypt, let's say, a "gplv2.txt" file somewhere... Because you'll use the SAME key to encrypt your other data. And unlike a FDE, since you have the two versions (crypted/unencrypted) and the NTFS encryption algorithm is well-known, you're vulnerable to a differential attack - which is not possible with a FDE. Obviously, if you encrypt a whole directory containing a lot of well-know files, then the differential attack is even easier...

You don't realize that, like most "vulnerabilities" reported regularly, you can't exploit these flaws with a normal system and with a normal mindset. I'm certainly not the best hacker in the world, but I destroyed enough protections in my digital life to know what is inherently dangerous or flawed, and what is secured, or at least a big enough pain in the ass, to be used without worrying about it.

To clarify, UAC is sandboxing. It's built-in. Also, Windows Sandbox exists.

No. UAC and sandboxing are two different things on Windows. Sandboxing isn't even possible on every hardware, and is only a light VM. Since you can't exchange easily files between the host and the sandbox (default is full isolation), it won't help in many cases just because you'll miss runtimes, drivers, frameworks, etc. A standard VM with automatically reverted snapshots is usually far superior, at the cost of more resources while executing it.

UAC, on the other side, is simply something that forbid access to critical (or even only "important") parts of Windows without an explicit consent. It works more or less like "su/sudo" on Unix.

Plausible deniability is how you prevent a death sentence in dogshit countries, NOT encryption alone, because either:

1. You are, by law, compelled to disclose your encryption keys, OR
2. Encryption is illegal.

A lot of people here would be pleased to hear how you consider their country - if I was an Aussie, I would be pissed off, for example, since this country have laws against both porn and encryption. Also, a life sentence isn't really better than a death sentence.

As usual, you don't understand shit about the subject. If you're smart enough, you can't reveal the encryption key because it was stored or 2FA-protected on another device that, unfortunately, got "accidentally" destroyed - or is hidden enough, for example as a "fortune" server somewhere...
Better a short jail sentence for "illegal encryption" rather than a long/death sentence for possessing (really) illegal porn stuff. Same difference as between misdemeanor and crime.

OpenBSD is Secure by Default :^)

The fact that you don't need manual commands anymore to enable FDE doesn't mean that the option is checked by default... Windows is as secure as OpenBSD regarding this, since you can also check (or leave unchecked) the checkbox at install time to enable/disable FDE.

And if you're so an OpenBSD's fanboy, what the hell do you do on Windows? Assume your choice and stay on this "alternative" OS - by "alternative", understand "one time you don't have drivers, one time you try to resolve incompatibilities between the 43 versions of the 12 libraries that does the same thing but can't work together".
I always wonder why such a "wonderful" OS has less than 0.01% market share: even Arch seems more popular than OpenBSD!

This is painful. Why are you like this?

Why are you dumb and ignorant? You are so ignorant that you overlook the basic courtesy of quoting my messages or my name when responding to me, which has been considered normal practice since the 90s...

And clearly, you live in Carebear's Land, or in your own world inside your head... You're like a lost redneck in the backwoods of Alabama who thinks that just because he has an automatic rifle, nothing can happen to him and that the Constitution will protect him from everything... Sweet summer child...

Again, you're neither cunning enough nor paranoid enough to talk about security. You just have a thin veneer of knowledge on the subject, and you think you're an expert because of that.

 

[Anon7483]

Yeah bud, I'm not reading all that. Got nothing more to say to ya. 'Cept that OpenBSD is an absolutely perfect operating system with legitimately zero faults :^)

Anyways guys, VeraCrypt and ACLs. Maybe add a 'lil FBE if you wanna be *extra*. Simple as, prove me wrong.

Cry moar. <3

 

[h3n741.g33k]

to all yall veracrypt bullshit.

C:/app data/programfiles/windows/(user profiles)/...

>local
>roaming

tldr short, ALL the save files and app cache data for your porn app games are stored here.

encryption does not interfere with this. This is discoverable by any user/admin and anyone "network browsing" your local drive/metadata.

This is not to speak of your "recent files" cache, images/recent images cache, web histories, download history etc...

Just stating from perspective of hardcoded app used metadata(unless running apps thru VMs you nuke after every use of those apps), these apps leave an imprint on your system. While save data and cache may not exactly be viewable in content, the folders and names that contain them can be quickly websearched and suddenly a snooper/intruder knows exactly what apps you are running.

Just saying, having actual "data security" beyond connection protocols is like um idk gee kinda important. Especially if in a region where certain content is like "you get the deaf pennalty" much less questionability of concern towards "is this censured or not?".

 

[h3n741.g33k]

You're not scheming enough, as I was saying... I thought I had given a sufficient clue, but apparently, you took everything literally, foolishly.

• Offline (i.e. without the targeted OS running), backup SAM and SECURITY data.
• Change user's password from standard interface.
  • You're warned that user will lose all access to his encrypted files.
  • I think that it's better / safer to use "net user" command to do that, to avoid possible side-effects and/or certificates deletion.
• Log into user's account with new password.
• Install whatever you need on his session: keylogger, spyware, etc. since you can do everything - either with his account or with administrator's account and UAC prompts.
  • This can be as dumb as copying the files (they will be decrypted if done properly) to a "hidden" place, using a proper tool that doesn't do raw copy, and it's even better if the tool has a bandwidth limitation and a "suicide exit".
  • Such a copier should even be launched with SYSTEM privileges, and through "RunDLL" to be near invisible.
  • A really machiavellian one would overwrite dummy files with the same size created for this occasion, so that user's won't even see a free disk space change. Software would jump across cores to hide its CPU usage - basic behavior is to use only idle time to really do copies, of course...
• Log out, put OS offline again and restore SAM and SECURITY data - this will restore his password, but whatever you installed is still there.
• Wait for his login and then his data.

It can even work on the only admin account, since you need to boot a live OS to put the targeted OS offline - Windows is a bit trickier than Linux for this, it isn't enough to backup "/etc/passwd" here.

BTW, you can check: change the test account's password forcefully, log in - OK, encrypted files aren't available. Now, go back to your admin session, change again the password to the original one and log again the test account: miracle, encrypted files are accessible again!

Another thing, but I never investigated this part, is something about EFS (the encryption layer in NTFS) :

"Also, in case of a user losing access to their key, support for additional decryption keys has been built into the EFS system, so that a recovery agent can still access the files if needed."​

This only sentence is enough for me to consider EFS as not secured enough in anything but a (near) trusted environment. It's way enough to encrypt "private" or restricted files (like a business proposal) at work. It's just a joke for "Confidential Defense", "Secret Defense", or illegal data.

And, AGAIN, FDE doesn't have these flaws...


You really don't understand anything... A real FDE doesn't leave ANY sector unencrypted, and a good one will even shuffle the sectors numbering so you won't even know where the "Sector #0" is located. An excellent one will also require a 2FA token to unlock the disk.

You don't understand shit about what is possible on an analyze machine, I even think that you believe that they are standard PC - at work, they are simple boards with a shitload of various connectors, custom FPGA & ASIC, etc. with another shitload of spy buses. You can plug anything on it, get a vampire connection on anything, get an interception connection on anything, and trigger any bus from any other bus event. We have guys at work able to make an UEFI bootloader, and to build custom Linux kernels and distros, or custom Windows - both being executed on encrypted hardware. Obviously, we also have tools to investigate such hardware when a problem occurs... And we are "only" a medium-sized enterprise, with poor capabilities compared to a governmental agency.

And for "well-know" files, you do realize that you can't find them on a fully encrypted disk? So you don't have the encrypted version to start any cryptanalyze? But it's VERY different if you're dumb enough to NTFS-encrypt, let's say, a "gplv2.txt" file somewhere... Because you'll use the SAME key to encrypt your other data. And unlike a FDE, since you have the two versions (crypted/unencrypted) and the NTFS encryption algorithm is well-known, you're vulnerable to a differential attack - which is not possible with a FDE. Obviously, if you encrypt a whole directory containing a lot of well-know files, then the differential attack is even easier...

You don't realize that, like most "vulnerabilities" reported regularly, you can't exploit these flaws with a normal system and with a normal mindset. I'm certainly not the best hacker in the world, but I destroyed enough protections in my digital life to know what is inherently dangerous or flawed, and what is secured, or at least a big enough pain in the ass, to be used without worrying about it.


No. UAC and sandboxing are two different things on Windows. Sandboxing isn't even possible on every hardware, and is only a light VM. Since you can't exchange easily files between the host and the sandbox (default is full isolation), it won't help in many cases just because you'll miss runtimes, drivers, frameworks, etc. A standard VM with automatically reverted snapshots is usually far superior, at the cost of more resources while executing it.

UAC, on the other side, is simply something that forbid access to critical (or even only "important") parts of Windows without an explicit consent. It works more or less like "su/sudo" on Unix.


A lot of people here would be pleased to hear how you consider their country - if I was an Aussie, I would be pissed off, for example, since this country have laws against both porn and encryption. Also, a life sentence isn't really better than a death sentence.

As usual, you don't understand shit about the subject. If you're smart enough, you can't reveal the encryption key because it was stored or 2FA-protected on another device that, unfortunately, got "accidentally" destroyed - or is hidden enough, for example as a "fortune" server somewhere...
Better a short jail sentence for "illegal encryption" rather than a long/death sentence for possessing (really) illegal porn stuff. Same difference as between misdemeanor and crime.


The fact that you don't need manual commands anymore to enable FDE doesn't mean that the option is checked by default... Windows is as secure as OpenBSD regarding this, since you can also check (or leave unchecked) the checkbox at install time to enable/disable FDE.

And if you're so an OpenBSD's fanboy, what the hell do you do on Windows? Assume your choice and stay on this "alternative" OS - by "alternative", understand "one time you don't have drivers, one time you try to resolve incompatibilities between the 43 versions of the 12 libraries that does the same thing but can't work together".
I always wonder why such a "wonderful" OS has less than 0.01% market share: even Arch seems more popular than OpenBSD!


Why are you dumb and ignorant? You are so ignorant that you overlook the basic courtesy of quoting my messages or my name when responding to me, which has been considered normal practice since the 90s...

And clearly, you live in Carebear's Land, or in your own world inside your head... You're like a lost redneck in the backwoods of Alabama who thinks that just because he has an automatic rifle, nothing can happen to him and that the Constitution will protect him from everything... Sweet summer child...

Again, you're neither cunning enough nor paranoid enough to talk about security. You just have a thin veneer of knowledge on the subject, and you think you're an expert because of that.

ignorance is bliss.

the clause of EFS helpservice gaining access to "confidential data/remote access" is beyond enough demonstration that there is absolutely 0 encrypted protection from mods/admins of that system

and

result--> 0 data security. The ISP can SEE and MONITOR everything you do and have direct access to your data/remote access to your terminal through user access backdoor.

aka 0 security and infact a direct security breach to said ISP provider which uses the "encryption service software" as basically a direct backdoor into your files/system.

The fact that they have 0 idea as to "why" this should even remlotely be avoided os kinda enough to rationalize, maybe X person is just "not smart enough" to idk have common sense. LMFAO...

Kudos on efforts to educate but I fear maybe falling on deaf ears.

 

[Anon7483]

Looks like somebody didn't read the documentation. And doesn't know what he's talking about. Again.

ACLs on the OS itself prevent users from viewing other's appdata folder. They're there by default. All that shit you mentioned is in the userdata folder. Protected by ACLs. An administrator can bypass this, but you should be the only administrator on your machine. No idea why you're bringing up connection protocols when literally nobody talked about that.

You're going to have to show me where it says an ISP gets remote access if you use EFS on a file. Seriously, what the fuck are you talking about?

Insanity.

 

[h3n741.g33k]

Looks like somebody didn't read the documentation. And doesn't know what he's talking about. Again.

ACLs on the OS itself prevent users from viewing other's appdata folder. They're there by default. All that shit you mentioned is in the userdata folder. Protected by ACLs. An administrator can bypass this, but you should be the only administrator on your machine. No idea why you're bringing up connection protocols when literally nobody talked about that.

You're going to have to show me where it says an ISP gets remote access if you use EFS on a file. Seriously, what the fuck are you talking about?

Insanity.

first off, stop thinking High level restrictions are actually secure. ACLs lock access at high level. Using cmnd prompt or lower level (which will be used by hackers since dos prompt is how they get into your junk in the first place).

ACLs restrict OS access to user app data and program/system files but this ONLY exists at the OS level.

connection protocols, thats ALL an encrypted VPN is, a custom connection protocol. it does absolutely ZERO to encrypt anything within your own hardware beyond the stock supplied "secure folder" only reason that's supplied, is that folder acts as the "networked shared folder" if you want to cloud sync your "secure folder" crossed multi devices using your vpn encryption user profile.

The EFS thing, they mentioned that there is a CLAUSE aka a legal contract line, in the docs/ToS that states "if keys are lost, Encrypted data access can be RESTORED to end users by way of a help agent"

meaning
the stupid MODS and ADMINS that run the EFS/NTFS service you mentioned, have DIRECT ACCESS and ABILITY to decrypt YOUR data. And while ToS might dictate they "need your permission" to do so, there is nothing stopping them from doing that with out permission as there's no way to KNOW on your end if they do or not and with ISP Admin access, if there even was such evidence record, they could wipe that.

As to HOW ISP Admin clients might be able to access your stuff, the stuff is encrypted by their algorythms tied to your User ID and your keys. Given data can be reclaimed with out keys, this means it is ultimately just your User ID+ their algorythm that encrypts stuff. Since they have both, they can decrypt and view your crap whenever they want.

Make sense? Is it basic enough?

 

[Anon7483]

first off, stop thinking High level restrictions are actually secure. ACLs lock access at high level. Using cmnd prompt or lower level (which will be used by hackers since dos prompt is how they get into your junk in the first place).

ACLs restrict OS access to user app data and program/system files but this ONLY exists at the OS level.

connection protocols, thats ALL an encrypted VPN is, a custom connection protocol. it does absolutely ZERO to encrypt anything within your own hardware beyond the stock supplied "secure folder" only reason that's supplied, is that folder acts as the "networked shared folder" if you want to cloud sync your "secure folder" crossed multi devices using your vpn encryption user profile.

The EFS thing, they mentioned that there is a CLAUSE aka a legal contract line, in the docs/ToS that states "if keys are lost, Encrypted data access can be RESTORED to end users by way of a help agent"

meaning
the stupid MODS and ADMINS that run the EFS/NTFS service you mentioned, have DIRECT ACCESS and ABILITY to decrypt YOUR data. And while ToS might dictate they "need your permission" to do so, there is nothing stopping them from doing that with out permission as there's no way to KNOW on your end if they do or not and with ISP Admin access, if there even was such evidence record, they could wipe that.

As to HOW ISP Admin clients might be able to access your stuff, the stuff is encrypted by their algorythms tied to your User ID and your keys. Given data can be reclaimed with out keys, this means it is ultimately just your User ID+ their algorythm that encrypts stuff. Since they have both, they can decrypt and view your crap whenever they want.

Make sense? Is it basic enough?

Sure. Thank you for keeping it somewhat short.

First off, ACLs do work at the low level. Access is denied when trying to access the userdata of other users through the command prompt. That's a ridiculous security oversight if that weren't the case. I don't think Windows would be that egregious. And yes, ACLs protect data from other users at the host level while the data is in use. VeraCrypt protects data at rest.

... I'm not sure why you're going off about VPNs. Do you think VeraCrypt is a VPN or something? Because it isn't.

If you're referring to the part where Recovery Agents can recover data, then no, ISPs are not Recovery Agents. Private keys are signed by the user, and additionally by the user/administrator that's a DRA if the administrator added that role to them. The DRA must also be added before the file was last encrypted or opened for them to decrypt that file - it can't be done in post. At no point is the ISP given remote access to your system just by encrypting a file with EFS. That's dumb as fuck. ISPs are also not administrators on your computer.

 

[Wisblade]

First off, ACLs do work at the low level. Access is denied when trying to access the userdata of other users through the command prompt. That's a ridiculous security oversight if that weren't the case. I don't think Windows would be that egregious. And yes, ACLs protect data from other users at the host level while the data is in use.

You're DENSE stupid, and ignorant to a fault. ACLs, or Unix permissions (or SELinux, too), are NOTHING once disk is offline, i.e. when the operating system that created them isn't running. Only FDE can protect you at this stage, since someone won't be able to mount the disk - therefore, he can't rummage in your files.

Simply boot on a Live OS, on an USB pen drive. Mount the (unencrypted) disk. You'll see ALL partitions, ALL files. You will be able to get ALL permissions, getting ownership, changing ACL and so on - and you can do that on ANY disk, including a Linux one from, a Live Windows. To be honest, you can do the same on an NTFS disk from a Live Linux. ACLs and Unix permissions/groups won't do SHIT. Dude, you will even be able to rummage into ANY registry hive, and you can easily replace "ntdll.dll" by a malicious one without ANY interference.

You can even dump swap files ("swapfile.sys" at root of volumes), get back files from the recycle bin, or use undelete software in order to resurrect "really" deleted files without the risk of having the OS nuking them because it's running.

And if you want to have nightmares FOR REAL, you can ALSO dump "hiberfil.sys"... Meaning that you can get an access to the RAM (data segment, heap and stack) of ANY process that was running when you set your computer to hibernation last time. Because this file isn't deleted usually at startup, so you can then find the RAM of... your shitty password manager, for example. Or a Kerberos admin token (education purpose: such a token is a good way to propagate a ransomware). Bonus points if you had VeraCrypt still running when you shut down your computer... because since it's open source, you can analyze precisely how data is stored in its RAM when the process is running, and therefore there is high chances that you can get your precious password to this encrypted volume you were so proud of.

If you don't believe me, burn "Hiren's Boot CD" or any similar LiveOS on a CD or USB pen drive, boot it on your own machine and try to "break" into your own USERDATA - or even the admin profile, it doesn't change shit. You'll see that you will be able to take ownership of ANY file, despite... being on a Live Windows! Yeah, Windows itself can simply RAPE another's Windows main disk without ANY problem. And without lube. An offline disk is pure DATA, they aren't protected at all until the owner OS is RUNNING and protecting files ACTIVELY. ACLs or Unix permissions are only bitsets, they don't do anything unless the OS is nice enough to check them before accessing a file.

Of course, you will have a hard time after that break in to cope restore proper ACLs, in order to get your Windows running fine, but maybe you'll learn something, this time.
You can do exactly the same with a Live Linux, obviously, the only difference is that the mess on ACLs will be greater than if you break in with a Windows - to be even more honest, Windows also often cause a mess on Linux disks, it's always better to break into the same OS to avoid side-effects.

And for EFS, we are now two people telling you that this IS NOT secure. You aren't able to read properly documentation (VeraCrypt) or searching yourself potential breaches for a system (EFS). If you fall from your ego to your IQ, you'll face a certain death! That's why I was saying, in my early messages, that you are a typical example of the Dunning-Kruger effect...

 

[Wisblade]

As to HOW ISP Admin clients might be able to access your stuff, the stuff is encrypted by their algorythms tied to your User ID and your keys. Given data can be reclaimed with out keys, this means it is ultimately just your User ID+ their algorythm that encrypts stuff. Since they have both, they can decrypt and view your crap whenever they want.

That is only when you use your ISP's VPN or tunneling. If you use third-party softwares, you can protect the data itself, but you can't hide which server you are connecting to (for example, they can see that you're visiting "lewdcorner.com", but they can't see what you're writing/reading exactly unless it is show in GET parameters (i.e. visible in the URL, and that's the default case for topics here).
That's why you need BOTH a VPN AND a HTTPS connection to keep a bit of privacy... Can be better through TOR, but it's slow and annoyng AF to setup - better to use it through a VM, in my opinion.

But an ISP can (near) always obtain information on what you were looking at on Internet, if they are compelled by the law. That's why really dangerous traffic should be done through a VPN on a public network, and never from home. And never from your smartphone, even if used only as a modem, but only from a fully-encrypted laptop, obviously.

Anonymity on the Internet only applies to the NORMAL people you're communicating with. For a government, the military, or secret services, your real name and address will be known within seconds - at best, within a few days, if they follow 100% of legal procedures...

 

[h3n741.g33k]

That is only when you use your ISP's VPN or tunneling. If you use third-party softwares, you can protect the data itself, but you can't hide which server you are connecting to (for example, they can see that you're visiting "lewdcorner.com", but they can't see what you're writing/reading exactly unless it is show in GET parameters (i.e. visible in the URL, and that's the default case for topics here).
That's why you need BOTH a VPN AND a HTTPS connection to keep a bit of privacy... Can be better through TOR, but it's slow and annoyng AF to setup - better to use it through a VM, in my opinion.

But an ISP can (near) always obtain information on what you were looking at on Internet, if they are compelled by the law. That's why really dangerous traffic should be done through a VPN on a public network, and never from home. And never from your smartphone, even if used only as a modem, but only from a fully-encrypted laptop, obviously.

Anonymity on the Internet only applies to the NORMAL people you're communicating with. For a government, the military, or secret services, your real name and address will be known within seconds - at best, within a few days, if they follow 100% of legal procedures...

This times 10,000 yes. (on 2nd one). Points I was mainly trying to illustrate though;

A) OS high level "restrictions" are pure BS as they only exist for "normie end users" of OS. Anyone browsing the server/terminal in prompt or terminal commands, either has or can direct backdoor complete DIR access unless you physically encrypt or VM + nuke VM with regard to data on the drives. (as in even when OS is running, your explanation on live OS break in is also accurate and a method but I was speaking mainly to "while ur online/when ur terminal is running the OS").

B) 90% of "vpn encryption" junk is ONLY on the data packet interchange, and half of these, the ISP running the client can have access to everything because the client ISP doesn't "need your keys" to decrypt. So its only protected in form of "confidential PII/PIE" aka only protected from other "end users". That these are mostly bunk services that are there to give normies n the elderly "warm fuzzy feelings" of "being secure" for their reciepts and biz info/personal files.

 

[h3n741.g33k]

Sure. Thank you for keeping it somewhat short.

First off, ACLs do work at the low level. Access is denied when trying to access the userdata of other users through the command prompt. That's a ridiculous security oversight if that weren't the case. I don't think Windows would be that egregious. And yes, ACLs protect data from other users at the host level while the data is in use. VeraCrypt protects data at rest.

... I'm not sure why you're going off about VPNs. Do you think VeraCrypt is a VPN or something? Because it isn't.

If you're referring to the part where Recovery Agents can recover data, then no, ISPs are not Recovery Agents. Private keys are signed by the user, and additionally by the user/administrator that's a DRA if the administrator added that role to them. The DRA must also be added before the file was last encrypted or opened for them to decrypt that file - it can't be done in post. At no point is the ISP given remote access to your system just by encrypting a file with EFS. That's dumb as fuck. ISPs are also not administrators on your computer.

So for high level user access restriction control a) this can be bypassed at low level in minutes whether it is online or by an offline user with physical access to the terminal. --> [edit to a) in ( parentheticals) below:

(as in even when ur OS is running. Wis's explanation of live OS breakin, is 100% accurate. Ur drive is just pure data, if the OS is not running, 0 security methods employed by the OS apply. So unless you physically encrypt the data, everything is readable. PLUS cuz windows/mac are BS, RAM is NOT encryptable. So anything in the RAM cache be it VRAM or CPU RAM, its all directly callable at any time).

b) you do not need to technically access the contents of app data dirs to identify what programs they are for. You just need the path chain dir listing. While at low level it is not entirely open (though can be backdoor-ed and is why DRM shit is still a zero day hack). at low level, you can still view the file structure and names of these folders which is all you need.

Tidbits on VPN is not entirely related to veracrypt, yes, veracrypt is a software you can use to physically encrypt your drive. There are some issues to that itself, but that gets highly technical and we still seem to be having trouble communicating fundamental data security basics so that discussion is for another day.

Point with VPNs is that your data on device even if you have a "secure folder" through that client, its not actually encrypted on your device. It is only encrypted in data packet exchange over a network. This is why to make security effective you need 1) VPN for communication 2) method of physically encrypting partitions on the server/drive 3) as wis outlines, with internet identifier protocols req by law (imei, mac address, sim serial id, ip address etc) you need an additional method of hiding/disconnecting this identifier data.

4) ultimately, for "true-ish" security, you need to confine your activity to an encrypted remote server and or blockchain to truly hide connection data or to run the software of questionable content on such an encrypted remote server/blockchain. Plus, your connections to this and from that to the net, both need VPN + further(method, there are several) serial end user identifier metrics to be hidden on both ways for both your connection and the remote server/blockchain.

This way, the questionable content, is never actually on your actual device. And it is safely stored on an encrypted drive in a tertiary location.

As to ISPs and remote access help agents, on remote access I was speaking about the actual help agents. If you "lost your keys" and need to recover the data, a help agent is remote casted to your device to help you with data recovery. That was the remote access portion.

On ISPs, I was talking about the service providers of the client software itself. That if you go with an option such as a "sync-share-able" encrypted folder via VPN cloud services, not only can help agents get into this data, but anything stored on the "secure cloud" can be decrypted by the admins of the client software/cloud server database. But this is only with SOME such services.

The some such services in question, being "any" client provider that in ToS/docs states that "if you lose your keys we can still help you recover the data".

The other bane of the net, 60%+ of companies are fraudulent AF. Since most "encryption" software clients and VPNs are strictly proprietary in their algorythms and methods, there is actually 0 guarantee that your stuff is actually both a) encrypted at all and b) that the client provider does not have direct back door access to it through trade secret proprietart means (if the data is even properly encrypted).

on "properly encrypted" there is a difference between actual encryption, and just "sorting the data" so it appears encrypted. That gets into heavy maths on calculous so I'll just end that here.

A bit on TLDR side but like make more sense now?

 

[Wisblade]

A) OS high level "restrictions" are pure BS as they only exist for "normie end users" of OS. Anyone browsing the server/terminal in prompt or terminal commands, either has or can direct backdoor complete DIR access unless you physically encrypt or VM + nuke VM with regard to data on the drives. (as in even when OS is running, your explanation on live OS break in is also accurate and a method but I was speaking mainly to "while ur online/when ur terminal is running the OS").

My point was only that, once offline, there is absolutely ZERO protection from ACLs, Unix permissions or SELinux. Not "a little", not "a bit", not "you need to be in computer field". ZERO. A single call to "cacls" and it's done for good.

When online, you need at least an admin access (remote or local, it doesn't matter) to rummage into another user's files. It may not be a problem - for example, by getting an access in cache to a Kerberos admin token (bonus point if it's a domain admin one) - but it's not "immediate" as it can be on an offline disk, where you can even break into the admin account of the OFFline disk with a standard user account on the ONline system.

But you're right, it can also be done online. It's trickier, in particular if you have a capable administrator running the server you try to break in. But you need knowledge at least to do it.
While, with an offline disk, even a script kiddy can get EVERYTHING without being delayed by anything else than the time needed to propagate ACLs/permissions recursively on the whole disk.

 

[h3n741.g33k]

My point was only that, once offline, there is absolutely ZERO protection from ACLs, Unix permissions or SELinux. Not "a little", not "a bit", not "you need to be in computer field". ZERO. A single call to "cacls" and it's done for good.

When online, you need at least an admin access (remote or local, it doesn't matter) to rummage into another user's files. It may not be a problem - for example, by getting an access in cache to a Kerberos admin token (bonus point if it's a domain admin one) - but it's not "immediate" as it can be on an offline disk, where you can even break into the admin account of the OFFline disk with a standard user account on the ONline system.

But you're right, it can also be done online. It's trickier, in particular if you have a capable administrator running the server you try to break in. But you need knowledge at least to do it.
While, with an offline disk, even a script kiddy can get EVERYTHING without being delayed by anything else than the time needed to propagate ACLs/permissions recursively on the whole disk.

yea I'm aware on offline. Point in highlighting low level backdoor and access even with OS online, was that this is tricker than when offline. As to offline, the sentance

High level restrictions only exist at the OS level.

This does imply non-functionality when OS is offline but it is a very subtle way of doing that, perhaps should have been more direct there.

 

[Anon7483]

You're DENSE stupid, and ignorant to a fault. That's why I was saying, in my early messages, that you are a typical example of the Dunning-Kruger effect...

Thank you, very cool. Maybe you should go ahead and reread the post you replied to.

So for high level user access restriction control a) this can be bypassed at low level in minutes whether it is online or by an offline user with physical access to the terminal. --> [edit to a) in ( parentheticals) below:

(as in even when ur OS is running. Wis's explanation of live OS breakin, is 100% accurate. Ur drive is just pure data, if the OS is not running, 0 security methods employed by the OS apply. So unless you physically encrypt the data, everything is readable. PLUS cuz windows/mac are BS, RAM is NOT encryptable. So anything in the RAM cache be it VRAM or CPU RAM, its all directly callable at any time).

b) you do not need to technically access the contents of app data dirs to identify what programs they are for. You just need the path chain dir listing. While at low level it is not entirely open (though can be backdoor-ed and is why DRM shit is still a zero day hack). at low level, you can still view the file structure and names of these folders which is all you need.

Tidbits on VPN is not entirely related to veracrypt, yes, veracrypt is a software you can use to physically encrypt your drive. There are some issues to that itself, but that gets highly technical and we still seem to be having trouble communicating fundamental data security basics so that discussion is for another day.

Point with VPNs is that your data on device even if you have a "secure folder" through that client, its not actually encrypted on your device. It is only encrypted in data packet exchange over a network. This is why to make security effective you need 1) VPN for communication 2) method of physically encrypting partitions on the server/drive 3) as wis outlines, with internet identifier protocols req by law (imei, mac address, sim serial id, ip address etc) you need an additional method of hiding/disconnecting this identifier data.

4) ultimately, for "true-ish" security, you need to confine your activity to an encrypted remote server and or blockchain to truly hide connection data or to run the software of questionable content on such an encrypted remote server/blockchain. Plus, your connections to this and from that to the net, both need VPN + further(method, there are several) serial end user identifier metrics to be hidden on both ways for both your connection and the remote server/blockchain.

This way, the questionable content, is never actually on your actual device. And it is safely stored on an encrypted drive in a tertiary location.

As to ISPs and remote access help agents, on remote access I was speaking about the actual help agents. If you "lost your keys" and need to recover the data, a help agent is remote casted to your device to help you with data recovery. That was the remote access portion.

On ISPs, I was talking about the service providers of the client software itself. That if you go with an option such as a "sync-share-able" encrypted folder via VPN cloud services, not only can help agents get into this data, but anything stored on the "secure cloud" can be decrypted by the admins of the client software/cloud server database. But this is only with SOME such services.

The some such services in question, being "any" client provider that in ToS/docs states that "if you lose your keys we can still help you recover the data".

The other bane of the net, 60%+ of companies are fraudulent AF. Since most "encryption" software clients and VPNs are strictly proprietary in their algorythms and methods, there is actually 0 guarantee that your stuff is actually both a) encrypted at all and b) that the client provider does not have direct back door access to it through trade secret proprietart means (if the data is even properly encrypted).

on "properly encrypted" there is a difference between actual encryption, and just "sorting the data" so it appears encrypted. That gets into heavy maths on calculous so I'll just end that here.

A bit on TLDR side but like make more sense now?

Very much a TL;DR but no, users cannot access data from other users in Windows via the terminal while the OS is in use and ACLs are active. This includes both files and directories. VeraCrypt protects data at rest.

We weren't talking about VPNs or how they make (or don't make) "secure folders" at all. EFS is also native NTFS encryption. You are not installing client software, Windows is capable of it by default. Files encrypted with EFS are non-recoverable if you do not have the original key or the file in question was not created or accessed after a DRA was put in place, and especially if the attacker has neither administrator privileges nor access to the original environment.

Personally, I don't think data you don't physically control is secure. That being said, yes, a server hosted in a location with a non-reciprocal agreement would technically be one of the best options if you're in an unfriendly country as long as the right prerequisites are in place. It will be expensive.

VeraCrypt is FLOSS. VPNs use OpenVPN and WireGuard protocols, and there are FLOSS clients for both. The algorithms used are public.

 

[Wisblade]

Thank you, very cool. Maybe you should go ahead and reread the post you replied to.

I've read it the first time, dude. And you're still wrong: ACLs don't work at "low level" - they operate several layers above what is truly "low level" in a mass-storage stack. As proof, ACLs aren't even a real thing if you don't use NTFS, for example. And it's exactly the same for Unix, obviously.

Everything related to isolation between users (including ACLs) is done, in fine, through a security token, because it would cost way too much time and CPU to check credentials each time. Obviously, the "normal way" to get one is to use credentials; therefore you'll need a login and password. But that's the "normal way", and, as I've already said it numerous times, you're definitively thinking too much inside the box to speak about security. I'll tell it another time: YOU MUST BE PARANOID TO CHECK SECURITY FEATURES. The problem lies not in the anticipated and expected threats, but rather in the unforeseen and/or unknown ones. Forget any already anticipated threat or problem, as it is precisely already foreseen. One must think outside the box, or for events classified as "improbable" or even "impossible".

But once you get a token, the process can use it to impersonate ANY access allowed by this token. Little by little, you may then obtain an admin's token, then a domain admin's one, and then, you're the king of the network. Because the "human factor" is such that most people do NOT reboot their computer once an admin came to unlock something they needed - whatever it was. Including through remote control - and there isn't ANY reliable way to do it, whatever protocol / software you can use. If you can get remote access to a computer, someone else can TOO. Full stop.

The "drama" here is that most computers aren't rebooted often, in particular servers, therefore the granted security tokens aren't flushed away. And most people (and even admins...) set their validity time to a way too long period: near 2 months isn't uncommon (2^32 milliseconds, in fact, so roughly 50 days).

To get back to thinking out of the box: that's why we use "dead man's switch" type of securities, for instance. Because death from a heart attack or an aneurysm is NOT a risk normally anticipated for a security position, since there are always TWO guards together... But both can die at the same time, either due to misfortune, or because of an attack! So, if the guards die suddenly, the alarm triggers a few minutes later, at worst. For the same reason, a train always defaults to applying brakes, and a constant action is required to allow its wheels to move: if the train driver dies, the train stops automatically a few kilometers further.

Applied to computer security, a dead man switch means something like UAC or start/stop validities - you ask for a security token, and you explicitely release it once you used it, with a default timeout set to a very short period, like 30 seconds at most. Because EVERYTHING done by user can be replayed by a process injecting messages/triggers inside other processes, excepted when something like the "Secure Desktop" used by UAC is triggered... And even that can be hacked, theoretically, if you managed to get inside kernel! It should rely on another CPU running a ROMmed software to be "perfect", this CPU being used to enable/disable physical address and data lines on the main CPU. Unfortunately, this cannot be done on a modular computer but exclusively on locked machines where access to peripherals is fixed by construction.

So, you CAN break into ACLs even on a live OS. And as I already proved, even your grandma can do it on an offline OS. OK, the trainee secretary can't. But you do realize that several people, including myself, are "a bit" above this level of competence regarding computers security?

Just for you to know: common OS are rated CC-EAL4. There are THREE levels above this one (and three below). You probably never encountered anything better than CC-EAL4, while in my domain, it's the MINIMUM rating, the one used for... non-critical display panels. We're not playing in the same league.

Very much a TL;DR but no, users cannot access data from other users in Windows via the terminal while the OS is in use and ACLs are active. This includes both files and directories. VeraCrypt protects data at rest.

Seriously, you're a complete joke, you know?

So, tell me: how the fuck can a ransomware infect and spread across a network, in this case? I'm using this example because, nowadays, it's the most common type of hack encountered...

And, for FLOSS software: who is responsible for their review and analysis? What are their qualifications? What is the deadline for submitting the analysis report? Is the code reviewed 100%? Is static analysis or, better yet, dynamic analysis used? Who takes responsibility for ensuring the safety of such software, and is there any guarantee? Code that is not reviewed by anyone, except malicious hackers, is by no means more reliable than proprietary code... I have seen more than enough bugs in "free" software to not have an exaggerated trust in them, especially when you can struggle to get any guarantee - be it in terms of corrections or diagnostic assistance!

One always gets what they pay for. If you pay nothing, draw your own conclusions, knowing that the engineers who worked on it, on the other hand, need to eat and have a roof over their heads.

 

[rwolf]

so Microsoft basically removed the ability to password a folder on windows 10 because your account is already protected. the problem is that it's really not, physically anyone can access your computer. so I have a password when entering windows, but why can't I just bypass that by using safe mode and then removing the password? unless it can't be done (pretty sure it can and at most I just need to access my email) and let's say I encrypt a folder (properties allows this) it means that unless someone uses windows via my user, they will never be able to access that folder?

I often don't lock my computer (again, anyone can probably hack it like nothing, this isn't an iphone, pc's are super easy to hack if you have physical access) I would just prefer if no one finds the 75 mother milf daughter lesbian incest videos I have inside that folder. pretty sure it's not that bad tho, people probably have some really fucked up stuff saved on their computers XD

I know there is a script I can run that basically allows me to lock the folder by making it vanish and then show it again via the script exe by using a password. however it works on a single folder so if it has any more folders inside of it, it won't work as well. basically what I want is for anyone to try to open that folder and not be able to without a password, and that you can't just download a hacking app and gz folder is unlock after 5 minutes. I also don't want to zip/rar it with a password because then I can't keep using it without extracting it every single time. another problem is renpy games for example that show up as game saves inside user folder/appdata/roaming.

it is truly annoying how programs tend to spread all over the place instead of remaining in a single location.

p.s.

I don't want to hide the folder, that would be too simple of solution and I happen to like everything unlocked and shown for faster access.

VeraCrypt is the best in my opinion and open sores.

 

[Anon7483]

Seriously, you're a complete joke, you know?

When I said I have nothing more to say to you, I meant it.