National Security VS Personal Security

National Security and Personal Security are two differing yet similar security paradigms with different ends and means. The public image of National Security is the Government must protect the privacy, integrity and confidentiality of the National Infrastructure and also those of the people it governs. There are many cases of the Government breaching such trust and faith the people have invested into them to protect the people's liberty, rights, privacy, security and integrity (LRPSI). Governments have also taken measures to intrude into the lives of the people it is suppose to protect by introducing or using multiple robust laws, measures and techniques to ensure that to achieve "National Security", the LRPSI of the people it is suppose to protect are frequently broken and intruded upon. In some uncommon cases, such intrusion of the people'sLRPSI may lead to cases of miscarriage of justice.

Below is a table that will quickly summarize my view of National Security and Personal Security in the current context.

Some may argue that National Security and Personal Security can go hand in hand but the current scenarios and political landscapes around the world implies that many Governments are willing to sacrifice their own people in the supposed name of "National Security" which makes the Governments' infrastructure strong but in turn weakens the LRPSI of the people as a whole.

National Security	Personal Security
Robust security on a governmental and national infrastructural level	Robust security on a personal level
Restriction of civilian security technology below it's own surveillance powers.	Personal security should be as strong as available
Subversion of LPSRI to achieve population control	Exercises full LPSRI rights via means of secure technologies
Maximum surveillance and subversion	Maximum counter-surveillance, anonymity and security
Top-down control of infrastructures and technoloogies	Individual personal control
Derive benefits via surveillance	Derive benefits via LPSRI

The current trend of National Security VS. Personal Security seems to be leaning more towards anti-LPSRI goals. Governments touting that National Security and Patriotism is not a Zero-Sum game is mostly false due to the fact that building a National Security infrastructure requires huge surveillance capabilities and the suppression of secure technologies that prevent surveillance capabilities from working due to the nature of surveillance which requires the possession of large amounts of personal information to be able to effectively execute population profiling, tracking and interdiction of possible threats / "threats".

Passwords in Database

It is inevitable that user passwords would be stored into databases for a good amount of applications in the wild. Most of the stored passwords in databases are weakly protected or left alone in plaintext. Application developers would usually blame security as a difficult task (which is very true) and those developers without adequate knowledge of computer security and cryptography would usually do a bad job at securing sensitive data like user passwords. Database makers may also be partially faulted for not adding features that ensure strong data security which database makers would usually point out that data security is not the main aim of their databases they distribute and would push the blame back to the application developers for not making their application data secure.

Indeed security is difficult but it can be easily solved if everyone (from the application developers to the cryptographers and database makers) were to sit down and put their minds together to make security easy for plain users. Below are some suggestions that I have to make data security easy for passwords stored in databases.

1. Make crypto-libraries simple for developers and with as little frustration connected to dependencies as possible. Developers should simply need to call an easy to use API that is straightforward. Developers should not need to know a lot on cryptography to use it. An example is developers should call "passwordEncrypt('bcrypt'.'this15MyPassw0rd');" and that's all they need. If they need to tweak settings, they can call "passwordEncryptTweak('rounds',10000000);" or something similar. The API documentations should be simple and concise for the developers to use.
   
2. Database developers may want to facilitate password security by introducing a Password type object that returns a hexadecimal string of the hashed/encrypted password. All Password type objects would be hashed/eencrypted according to the algorithm set inside the database properties and should support common password hashing methods like BCRYPT, SCRYPT and PBKDF2. Furthermore, a 'authenticate()' command can be issued against a Password object that takes in a string to return a boolean output whether the password object has been authenticated correctly. This will facilitate password security stored in databases.
   
3. Store user accounts and passwords in a highly protected computer system with limited user access. One way is to setup a user database server that have a strict set of protected API that the application have to call. During authentication, the application server would pass user login request to the user account server that would valid the login before returning the response to the application server. Only the application server should have access to the user account server.
   
4. Make use of login services from login providers (Google, Facebook, Twitter ...) instead of storing user passwords and handling logins on your own.