Jorpho wrote:

computergeek92 wrote:

And then what when the encryption software is so obsolete and full of holes? Then that's it then, right?

If you're that concerned about the security of your data (and what sort of data could you possibly have that you think anyone else would care about, really?), then switching to Windows 3.x is not the answer. Disconnect your computer from the network and store it in a bank vault, or something.

The way I see it, for the vast majority encryption is like a bicycle lock. There's really nothing you can do to stop a sufficiently-determined thief from walking off with your bike (or even just parts of your bike); the best you can hope for is to be sufficiently discouraging as to make the thieves want to target someone else.

I already have a file server running Server 2003, which works well, I just want to broaden my list of choice of secure OS. The files would already have copies on the server anyway.

If I wanted maximum security for an OS I would go for OpenBSD personally. I don't really trust any Windows OS to be really secure, mostly because of the usage of NT derivant kernels even in the newest versions.

A lot of my user created files work only in Windows and I find XP-era Windows to be far less glitchy than the modern day Linux i've used. That's just my experience. I tried Zorin Ultimate and it didn’t work as well as Zorin Core, for example. I want to use my old computers forever and hopefully in 20-30 more years hackers forget how to hack them because the OS would be much older, obsolete, and generally unused. Sorry if I come off as naive.

I guess that none of today's viruses are targeting 16-bit systems so even getting online with Win 3.11 should be safe, but maybe I'm wrong.

As has been noted in the other thread, while viruses floating around might not work on Win 3.11, a lot of other stuff on the Internet isn't going to work in Win 3.11 either.

As far as security in the sense of protection from malicious attacks goes (as opposed to security in the sense of protection from data theft), Win 3.11 is already a pretty dangerous threat to itself.

On Linux the distro you use is important, for example Arch Linux seems to work for a lot of people, Debian is legendary for it's stability etc. As long as the Windows kernel is based on the same NT codeline, there will be vulnerabilities from the 90's, that just haven't been found yet. I understand the usage of old operating systems, but I wouldn't trust on their security, ofcourse the simplest way is to keep them out from the internet altogether.

Aideka wrote:

there will be vulnerabilities from the 90's, that just haven't been found yet

That, however, works the other way around as well. An exploit targeting a recent OS might also be able to attack an older one with minor adaptations (or none at all), provided that the vulnerability is there.

Presumably the appeal is that an exploit targeting a recent OS will probably not be written in 16-bit code (as all 64-bit systems would be completely invulnerable) and hence an OS that runs only 16-bit code will be safe.

ETA: As per Wikipedia, all versions of Windows right down to 3.0 were susceptible to the the Windows Metafile vulnerability, but "attack vectors only exist in NT-based versions of Windows".

Indeed, I was talking about the 32bit NT codebase mentioned. After all, recent versions of Windows do still come in 32-bit flavours.

computergeek92 wrote:

Sorry if I come off as naive.

Your objective just doesn't make any sense.

Using vintage things for its own sake is a heap of fun, but you're only making life difficult for yourself by trying to restrict your non-hobby activity to your vintage environment.

Old OS'es with vulnerabilities and unpatched bugs, encryption schemes that are weak or defeated, hardware with unknown remaining lifespan, there's just too many reasons not to keep important, private data anywhere near the things.

By choosing vintage, you're not really asking "What's the most secure?", you're really asking "What's the least insecure?".

We all agree it's fun to play with these things, it's the whole reason Marvin exists, but for your serious computing requirements, you're shooting yourself in the foot to not use modern hardened OSes with privilege separation, encryption, and most importantly updates.

In Windows 3.1 days, the screen saver was often used to provide password protection.

Alternatively, the PCs had to be secured by mechanical locks and password protection at BIOS level.

There were even floppy protection devices with locks..

psychz wrote:

NTLM/user account password protection can be circumvented via means of booting from a CD and either resetting the password (to get into Windows) or using tools such as l0phtcrack to crack it.

If you don't know what the fuck you're doing, erasing the passwords is almost the same to using a nuke to open a door. If the owner was careful and had a proper set up security, erasing NT password will fuck any files encrypted with EFS, with no method to recover them in an unencrypted way, and it will kill all the secure key encryption stores from the registry. Basically the same result as just formatting the PC. Cracking method only works if owner had enabled LM hashes for authentication with older SMB versions, like Win9x/Win3.x/DOS. New security storage hashes can't be defeated without brute force, and for that you would like to have a super computing cluster, and pray for the owner using a stupid short password combo.

psychz wrote:

One can always boot DOS from a floppy with NTFS4DOS, grab the samfiles and take them elsewhere... There is always a way.

Even if you get access to the sam files, if the owner was smart enough and disabled the older ways to hash the passwords, you will not be able to crack them easily. And as i said before, erasing passwords automatically makes urecoverable any file crypted with the erased key, if the owner was smart enough to set up his/her computer security policies decently.

Aideka wrote:

If I wanted maximum security for an OS I would go for OpenBSD personally. I don't really trust any Windows OS to be really secure, mostly because of the usage of NT derivant kernels even in the newest versions.

Hahaha, funny. Wtf has to do the security level with the kernel choice? Both system architectures, when configured correctly, are fully multiuser and multisession systems which implement access controls and security mechanisms. NT Architecture is very powerful and flexible, allowing anything you want to do with it, and implement security in the way you want.

Despite what linux/*nix crazers and evangelists say, NT isn't more or less secure than Linux/*nix. Ofc desktop versions come with lesser security policies applied, to balance with joe users convenience, because joe doesn't like security if it interferes with "ease of use" feature. But nothing stops users to apply strict security policies to your NT setup if you want to.

hyoenmadan wrote:

Aideka wrote:

If I wanted maximum security for an OS I would go for OpenBSD personally. I don't really trust any Windows OS to be really secure, mostly because of the usage of NT derivant kernels even in the newest versions.

Hahaha, funny. Wtf has to do the security level with the kernel choice? Both system architectures, when configured correctly, are fully multiuser and multisession systems which implement access controls and security mechanisms. NT Architecture is very powerful and flexible, allowing anything you want to do with it, and implement security in the way you want.

Despite what linux/*nix crazers and evangelists say, NT isn't more or less secure than Linux/*nix. Ofc desktop versions come with lesser security policies applied, to balance with joe users convenience, because joe doesn't like security if it interferes with "ease of use" feature. But nothing stops users to apply strict security policies to your NT setup if you want to.

I'm with you at this one, every OS has its flaws. But it's funny that this family of *nix got mentioned.
I mean, I'd rather have one or more open windows at the front side of my house than an open door at the back. 😉

hyoenmadan wrote:

If the owner was careful and had a proper set up security, erasing NT password will fuck any files encrypted with EFS,

Agreed.

...and for that you would like to have a super computing cluster, and pray for the owner using a stupid short password combo.

...or big enough rainbow tables, and more or less pray that the password is covered by them.

Even if you get access to the sam files, if the owner was smart enough and disabled the older ways to hash the passwords, you will not be able to crack them easily. And as i said before, erasing passwords automatically makes urecoverable any file crypted with the erased key, if the owner was smart enough to set up his/her computer security policies decently.

You do realize that the OP wasn't talking about encryption, but rather plain account password protection, don't you?

Wtf has to do the security level with the kernel choice?

Opensource software (including, but not limited to the kernel) can be audited by both the developers and third-parties. Proprietary software uses more or less a "security by obscurity" approach. Both have their pros and cons. Depends on who/what you trust more.

Both system architectures, when configured correctly, are fully multiuser and multisession systems which implement access controls and security mechanisms. NT Architecture is very powerful and flexible, allowing anything you want to do with it, and implement security in the way you want.

Indeed.

Despite what linux/*nix crazers and evangelists say, NT isn't more or less secure than Linux/*nix.

Exactly, it's all a matter of configuration, and desktop Windows configuration out of the box isn't going to help a lot.

https://nakedsecurity.sophos.com/2016/06/16/b … -need-to-patch/. This is the kind of stuff I meant earlier when talking about the same codebase being in use for two decades or more. Sure, it may not be a kernel exploit, but still shows the risks of including decades old closed source code on the OS.

EDIT: I am personally just fine running Windows on my computers, that are for normal desktop use, but if I setup a server of somekind I rather use opensource code just because there IMO is less chance of exploits working 20 years down the road.

Aideka wrote:

but if I setup a server of somekind I rather use opensource code just because there IMO is less chance of exploits working 20 years down the road.

🤣

CVE-2014-6271/7169, the so-called "ShellShock" exploit, discovered and patched in 2014, was present in bash from its initial release in 1989.

psychz wrote:

Even if you get access to the sam files, if the owner was smart enough and disabled the older ways to hash the passwords, you will not be able to crack them easily. And as i said before, erasing passwords automatically makes urecoverable any file crypted with the erased key, if the owner was smart enough to set up his/her computer security policies decently.

You do realize that the OP wasn't talking about encryption, but rather plain account password protection, don't you?

Well, if this is the case both *nix and windows are vulnerable to it. The same trick you can do with the SAM files you can do with the *nix PASSWD and Keyring files.

psychz wrote:

Wtf has to do the security level with the kernel choice?

Opensource software (including, but not limited to the kernel) can be audited by both the developers and third-parties. Proprietary software uses more or less a "security by obscurity" approach. Both have their pros and cons. Depends on who/what you trust more.

But being opensource doesn't automatically make code secure as many people think, it has to be audited first and it has to be audited by people who know about these matters, so generally them are run by big companies in order to satisfy their customer requeriments, or paid by the community. Without an audit, Opensource code ins't more secure than any other code, and Heartbleed exploit shows it. There are many opensource components that never have been audited, or only certain parts have been audited.

There's also people who like to apply any patch found in the net to their software codes, without knowing what these things really do. Probably them aren't malicious, but them aren't audited, so them can introduce actually exploits without the creator or the user knowing it.

By contrary, at least in Windows case, since both desktop and server revisions share the same codebase, generally desktop users can benefit from the large and extensive security audits who MS applies to kernel and base components code, in order to fullfill their big customers requeriments. So, like with *nix, as soon as you're in the latest revision and patch level, your OS core components will be less vulnerable.

But even i recognize the advantage of opensource, even if i don't like *nix architecture OSs, so my support will go to ReactOS. Even if they go slow by matter of their project being absurdly big, they are still doing a great work every day to bring up an Opensource alternative based in the NT architecture. Form them i've learned how powerful and flexible NT architecture can really be. I can't wait for the end of GSoC season, many improvements are coming to them.

psychz wrote:

Despite what linux/*nix crazers and evangelists say, NT isn't more or less secure than Linux/*nix.

Exactly, it's all a matter of configuration, and desktop Windows configuration out of the box isn't going to help a lot.

Because desktop OS objectives in this matter for MS are:
1- Friendly configuration and max program compatibility as default, even if they need trade security for that.
2- Is responsibility of their users set up their own security measurements, so them don't conflict with user workflow.

But any of them have to do with NT architecture at all, or even in some cases with windows code. That's my point.

hyoenmadan wrote:

Well, if this is the case both *nix and windows are vulnerable to it. The same trick you can do with the SAM files you can do with the *nix PASSWD and Keyring files.

Of course, with the main difference that file systems utilized in *nix used to use ACLs long before NTFS was an option. NT/2K and XP can be installed on FAT variants as far as I know, which features neither encryption nor permissions/userlists.

Regarding the rest of your post, I agree 100% 😀

as long as physical access is possible any data can be removed, its a matter of how long it will take whoever wants it. Given enough time you could decrypt the hard drive storing the NOC list. That's why you always want to restrict physical access.

Want to make it hard to remove your drive, a pad lock is easy to pop off, go with side panel secruity screws, less likely someone will have brought that special 7 star screw driver with a hexogonal pin in the middle. Better yet do it the government way, and hire private security to patrol 🤣

psychz wrote:

Of course, with the main difference that file systems utilized in *nix used to use ACLs long before NTFS was an option.

NT features security and ACLs since WinNT3.1. It also features extended attributes, which can be used by things like the LanMan addon for Macintosh, which uses them to store Resource Fork data in the NTFS drive. NTFS has been supported and present there since NT3.1. A different matter is the owner using it, which many users didn't to keep the system compatible with DOS/Win3/Win9x. But isn't the system fault.

Btw, in NT you can also deny "system" users to access files, and deny permission changing in these files for any user who isn't the owner, effectively locking them to the user account. In such state you will not be able to retrieve them by any FS driver who respects ACL permissions (So at least standard WinPE CDs are useless). Then your only choices are compiling a driver which doesn't respect ACLs, generally using a custom *nix bootcd and drivers for that, or retrieving them with a low level FS recovery utility, things which can be used against a *nix system too.

psychz wrote:

NT/2K and XP can be installed on FAT variants as far as I know, which features neither encryption nor permissions/userlists.

Which isn't a supported/recommended configuration by MS. You can do it for sake of compatibility, but then will be your own fault if certain system features aren't there because what you did. This also has nothing to do with NT architecture robustness, but certainly it show flexible it can be.