full-disclosure - M$ - so what should they do?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: aditya.deshmukh at online.gateway.technolabs.net (Aditya, ALD [ Aditya Lalit Deshmukh ])
Subject: M$ - so what should they do?

> Well, lets see, moving away from the Registry (single point of failure) 
> would be a good step.

this should be done the first thing, however the registry has backups and other ways to recover from failures howevert the builtin failure machanisms are not sufficent

> Separating the operating system from programs would be great, I don't 
> like the fact that everything and it's brother thinks it can or should 
> dump files into the system directory.

that is the admin responcibility to lock down the system dir and the app programmers that require write access to program files folder. the confiration can be stored in the user profiles or system profiles if need be but programs requiring access to programs files dir is the responcibility of the programmer

> What else is flawed? What other changes should be made?

there are many small small things which would be great if they were changed like the some undocmented parameters n functions in the kernel etc etc

-aditya
??????????????????????????????????????????????????????
?b???v?"?.axZ?x??????Gb?*'??.?[kj???.?j)m???r??