All Unix users are aware of the DAC (-rwxrwxrwx) that we always use to prevent others from accessing files we don't want them to. But there are times when you want more than that.

You may say:
1. I want to prevent myself from accidentally deleting a file despite having -rwxrwxrwx permissions.

2. If you have 000 permissions for a file, then you cant delete it without changing the permissions first. But you can straight away do a "rm -f" .Many people are just used to using the "f" flag(I sometimes wonder if the "f" flag meant "force" or something else). If you are a Linux sys-admin and you are sharing the root password with fellow admins, then you definitely need something to warn your fellow-admins from doing something wrong accidentally. The traditional DAC does not allow you to this. For DAC "root" is as good as God.

3. I want to prevent every body (including root) from deleting the file or writing to file, BUT YOU WANT TO ALLOW THEM TO ADD DATA TO FILE. ie, allow only appending.

A very less know Linux command "chattr" allows you to do precisely these by making the file immutable. This works only for EXT2/ETX3 file-sytems only. If you set the immutable attribute for a file, it means that it cannot be modified, deleted, renamed and no hard links can be created to this file.

Even a root user attempting to delete this file with get the message "Operation not permitted". Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

chattr +i <filename> sets the immutable attribute of the file.
chattr -i <filename> clears it.
lasttr <filename> will show the status of the attributes.

This not-so-popular command has got a bunch of other attributes that you can set either to improve the security of your system or even to increase performance.

Using the +a attribute you can make the file to be opened only in append mode. (-a to remove the attribute.

For a security sensitive file-system you may want to set the "+s" attribute which will make sure that when you delete the file, the contents in the hard disk are all zeroed out.

Read the man pages of lsattr and chattr for more details and limitations/bugs. The full features of chattr are not yet available.

As promised in my post on Thoughts on password management here is a step by step guide on how someone can capture your login id and password while you login into a website that does not support HTTPS (HTTP over SSL).

A little basics first. HTTP protocol is based on clear text interchange of data. It is an application layer protocol with TCP and IP in the underlying layer. It means that anybody who can capture a HTTP packet traveling over an Ethernet network can read all information you sent.

When you type http://blog.netotto.com/index.php, your browser sends the following request:

    GET / HTTP/1.1\r\n
        Request Method: GET
        Request URI: /index.php
        Request Version: HTTP/1.1
    Accept: */*\r\n
    Accept-Language: en-us\r\n
    Accept-Encoding: gzip, deflate\r\n
    User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)\r\n
    Host: blog.netotto.com\r\n
    Connection: Keep-Alive\r\n

This is a HTTP GET request, the important part is just the GET and the Host lines. The server responds to this again in clear text, that your browser can understand. Here is how it looks:

   HTTP/1.1 200 OK\r\n
        Request Version: HTTP/1.1
        Response Code: 200
    Date: Sat, 15 Sep 2007 10:41:22 GMT\r\n
    Server: Apache/2.0.54 (Unix) PHP/4.4.7 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2\r\n
    X-Powered-By: PHP/5.2.3\r\n
    Expires: Thu, 19 Nov 1981 08:52:00 GMT\r\n
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0\r\n
    Pragma: no-cache\r\n
    Vary: Accept-Encoding\r\n
    Content-Encoding: gzip\r\n
    Content-Length: 6611\r\n
    Keep-Alive: timeout=2, max=100\r\n
    Connection: Keep-Alive\r\n
    Content-Type: text/html\r\n
    \r\n

    Content-encoded entity body (gzip): 6611 bytes -> 26607 bytes

This is followed by the HTML page (index.html) in clear text.

If you are at the login page of a non-secure web page your login and passwords can easily be read by somebody on the network. All you need is a network packet capturing tool.

On an Ethernet, the electrical signals (to which your HTTP packet finally resolves to while traveling on the wire) is actually readable by all the computers in your Ethernet LAN. The network card in normal operation mode (called non-promiscuous mode) does not read packets that are destined for somebody else.

A packet capturing tool like Ethereal can ask your network card to be in promiscuous mode and read all packets. These includes packets destined for other machines in your LAN.

You can download and install Ethereal for Windows from the Ethereal Download Page and install it and follow the following steps to convince yourself that sending data over a non-secure channel (a non HTTPS website for example) is very un-safe.

Lets jump straight into the steps:

In this example, I have installed Ethereal on the same computer from where I will be attempting to login to a non-ssl website like www.youtube.com . You can however run the Browser and Ethereal on different computers in your LAN which are in the same subnet (Eg: Browser on your computer at office and Ethereal on your colleague's computer).

1. Open the youtube login page (http://youtube.com/login?next=/index) in your browser. Note: its http and not https. I type in "shuva" and password as "testpassword"

2. Start Ethereal (I am using version 0.99.0)

3. Lets configure it so that it captures only HTTP packets. We dont want to capture hundreds of other packets. From the menu bar, select Capture--->Options. In the Options dialog box, choose the correct n/w interface if you have more than one. I have something like "Intel Pro/100 VE". In the capture filter type in "tcp port http". This means we will capture only http packets.

4. Click the start button to start the capture.

5. Click on the login button on your browser.

6. Back to Ethreal, click the stop button on the popped up dialog box.

The Ethereal window is divided into 3 parts,

the upper part listing the packets,

the middle part showing the selected packet in human readable form and properly divided into the layers (HTTP/TCP/IP/Ethernet/Frame) and

the lower part showing the raw bytes of the selected packet.

In the upper part, where you many lines with lots of IP addresses, search for the line that has "HTTP" and "POST /login?"

In the middle part click on "+" sign that says "Line-based text data". There is your login and the password. Just above the "Line-based text data" is the HTTP request that you sent to youtube.

Here is a screen shot:



Below is the HTTP request that went through the network:

    POST /login?next=/index HTTP/1.1\r\n
        Request Method: POST
        Request URI: /login?next=/index
        Request Version: HTTP/1.1
    Host: youtube.com\r\n
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6\r\n
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
    Accept-Language: en-us,en;q=0.5\r\n
    Accept-Encoding: gzip,deflate\r\n
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
    Keep-Alive: 300\r\n
    Connection: keep-alive\r\n
    Referer: http://youtube.com/login?next=/index\r\n
    Cookie: dkv=; GEO=a78121630c1e9382b3cf8d384cd0d399cxYAAABJTixhcCxoeWRlcmFiYWQsLCwsLC0x; LOCALE_PREFERENCE=86d1d09eefe6b79b4068000ce05518a4dAUAAABlbl9VUw==; LOGIN_INFO=; VISITOR_INFO1_LIVE=D6Jub46OfWo; use_hitbox=72c46ff6cbcdb7c5585c36411b6
    Content-Type: application/x-www-form-urlencoded\r\n
    Content-Length: 93\r\n
    \r\n
current_form=loginForm&next=%2Findex&username=shuva&password=testpassword&action_login=Log+In

Disclaimer: My selection of youtube.com for this demo is not to prove that youtube.com is unsafe. I just wanted a very well known website. My intention of writing this article is not to encourage people to read somebody's else packet from the network but to demonstrate to users that visits to non-secure sites are not safe and you should therefore never select a password for such sites which you are reusing for a secure site like your email or banking sites.

Relevant posts:
1. Thoughts on password management.
2. Storing all your password safely.

I have been searching for a good free XML editor which this two basic requirements:

1. Allow editing XML files in code and also allow me to expand and collapse sections (like IE does)

2. Can perform XSD validation.

Having used Altova XMLSpy in my last job, I knew something thats free cannot probably have all features like XMLSpy.

Unfortunately I landed up no-where.

I started with Microsoft XML Notepad, but it wont allow me to edit in code. Otherwise it does have a lot of features. Its very important for me to edit in code.

Then I installed Cooktop but after using it for a few minutes I realized that when a XSD validation fails, the error messages that gets popped says that it could not find the definition of the root element in the XSD file. It wouldn't pin-point the error.

It means if you type in a string for a attribute which is defined as xs:integer, validation thinks that the root element is not defined. Na! Not good.

Then I tried using with my favorite editor, Xemacs but just could not figure out how to make it validate against .xsd. I found a lot of help to validate against DTD and SGML validation, but not XSD.

However in this process, I found a very useful comparison chart of all the XML editors available. Its very exhaustive and the comparison is too detailed. Here it is:

Choosing an XML editor by hijs van den Broek.

Following the last discussion on passwords, we felt the need to writing down the passwords somewhere. There are n number of products out there that you buy to get a password storage solution.

I wanted something that is free and does not require too much work to retrieve. I ended up using my Unix editor vi. The -x option with vi uses crypt to encrypt the data using a user specified password. When you create a file the first time using the command vi -x myfile , it will prompt for a password. When you save the file, the data is stored encrypted. The password itself is not stored. When you open the file next time (without the -x option) it will ask you the same password. Only if you supply the same password, the text appearing will make sense to you, else its all garbled. This is much safer then getting a message "Incorrect Password" as this makes life difficult for the hacker.

The data transformation is a simplified simulation version of the Enigma machine.

So if you can manage to remember a master password you can store all your passwords on this encrypted file and access it with your vi editor. You can take a backup of this file and store it somewhere else. This encrypted data can only be decrypted by a trial and error and it's safety is proportional to the complexity of your master password. Some people even try to encrypt more than once or use some other transformation above it like zipping the encrypted file with another password before keeping a backup.

I personally keep the layout of the user names and password inside the file in an innovative scattered manner (like keeping the username and password far away from each other that only I can understand) and a brute-force break of a part of the file will make no sense to the hacker.

Warning: This method does not provide security against tampering. Someone can make the encrypted file unusable if he/she has access. I suggest a backup.

Unfortunately the simple editors with Windows dont come with such a piece of beauty. Cygwin can help you run vi on Windows.

In today's world, and specially for a person who uses Internet a lot (you are one of them if you are reading this blog), it is often a very difficult task to remember and manage passwords and PIN codes. Everybody recommends that you set a unique password and memorize it. Well, it is not humanly possible to set different and difficult passwords and remember them all. Humans cannot program their brain cells to behave like a hash-table of <website <username, passwords>>. But we a strong in built neural network.

There are numerous articles on the Internet that would suggest best practices. Follow them and add some creativity into it. They are definitely useful.

Read Password Management Best Practices by MTECH Identity Management.

Today I will discuss those practices that I have learned over the years and those that I can follow.

The first very three very important attributes of passwords to bear in mind:
1. The strength of the password in itself.
2. The mode of travel of the password over the network to reach the server.
3. The format in which the password is stored in the server.

Most people ignore the second and the third point.

Case 1:
Imagine a very strong password like "TsxW&^347F2" which is strong in itself, but stored in plain text on the server.

Case 2:
Imagine a very strong password like "TsxW&^347F2" which is stored encrypted on the server but it is transferred in plain text over the network.

Case 3:
Imagine a server which accepts only encrypted traffic, stored the password with a one way encryption but the password chosen by the user is "flower". Shame! Shame!

All the above cases leads to compromise of your password. All the three factors should be fool-proof.

However, as a user you don't have any control over the way the passwords are stored at the server (problem 1).

You may not also have control over the way the password is transferred over the wire(problem 2).

You do have control over choosing a strong password, but very difficult to remember so many strong passwords with their corresponding user name. (problem 3).

You also need to choose a user name which is unique. Every time you enter a user name, it says its taken and you end up having so many user names for so many website.(problem 4).You wish your parents had given you a name that does not show up in Google search. Curse not your parents before you manage to give your child one such name and he/she does not hate you.

The way I address these problems may not be 100% save, but I know that it is pretty good from what I have learned while working as a developer for a Software Security company.

One idea is to use the same password everywhere so that you can remember, but not before creating a set of such passwords for categories of sites. I give one password for every category and use the same password (but with a pinch of salt).

The categories:
1. For websites which if compromised, can cause huge monetary loss. This includes your online bank accounts, credit cards, e-commerce websites. All of them use secure communication channel and we can reasonably assume that they store passwords securely.

You need to choose a very hard password, that is very difficult to crack. Something like "TxW&^7F2" and one which you can remember. Optionally you can add another character or number to it based on which site it is for. Example: TxW&^7F2paypal for your paypal account. This becomes the pinch of salt. Consider this postfix as your home grown crytographic salt. Get innovate, derive a salt and dont tell you friends about your salty logic.

2. For websites which if compromised, cant cause monetary loss but can damage your identity in the e-world, can cause grave non-monetary losses and potential monetary losses too. This includes your email websites, your bill-paying sites, your office and home computer and networks, etc. These sites may secured or may not be. They never send your passwords via email, but send a link back to you to reset your password.

You need another set of password which is in NO WAY lined to "TxW&^7F2". Hackers know that Home sapiens have the tendency of keep the same passwords. Keep something different. Keep a similar passwords for secure websites like https://google.com or your office NT domain.(or maybe keep the office away coz your superior may suddenly call you in the middle of the night and ask you your password). Be sure not to use the same password for non-trusted sites. The ability to add a innovative salt into this category practically depends on your personality. I dont.

3. Those sites that your don't care even if you loose your password. Its just that they need a user name and password to use their service. They even send back your old password via email if you request it. Its for sure they are not storing it securely.

For this keep a crap password, the complexity of which depends on your own capacity to remember, but never the same password which you have used for the other two categories.

OK, by now you have so many passwords and user names. If you use a formula it is easy to remember, but we all know its easy talking and blogging then remembering. There will be a site that does not take that special character.There is one website where I just had to use a weird user name and there is another one which generated a user name for me.

We also generally end up remembering passwords we often use daily and our magic formula formula probably works, but we still feel the need to write down the password somewhere. Dont we?

Enough of this today, I will write about ways I use to securely store these passwords in one of my future post and it will not be an advertisement of a product/solution that you need to buy.

I will also demonstrate (step by step guide) to you how your password can be read over the network when it is passed over a non SSL channel in yet another post. I also did not touch over the potential problems caused when passwords are stored insecurely at the server. But I guess I dont need to. But I will talk about one of the most commonly used techniques used by websites to store your passwords and how vulnerable they are.

Stay tuned! Your thoughts and ideas are welcome.