Shuva's blog
Storing all your password safely. 
Tuesday, September 11, 2007, 07:01 AM - Tips and Tricks
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.
add comment ( 78 views )   |  0 trackbacks   |  permalink   |   ( 3.1 / 61 )
Thoughts on password management 
Sunday, September 9, 2007, 07:01 AM - Ideas and Thoughts
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.

2 comments ( 108 views )   |  0 trackbacks   |  permalink   |   ( 3 / 52 )
A software license aimed at making the environment safer 
Friday, September 7, 2007, 07:01 AM - Analysis and Reviews
While installing Wordweb today, I came across one of the most interesting software licensing terms and conditions that I ever read so far. It says:

You may use the program free of charge indefinitely only if

* You take at most 4 flights (2 return flights) in any 12 month period
* AND you do not own or regularly drive an SUV (sports utility vehicle).

If you do not qualify you must uninstall the program after the 30-day trial period or purchase WordWeb Pro. The license is designed to provide a small incentive for people with massively unsustainable emissions to cut down.

Whenever a user no longer meets the above requirements, and they have installed the product for more than 30 days, they must uninstall the product or purchase WordWeb Pro; otherwise it is software theft.


Read the full license agreement here.

I am installing this product after more than 3 years and I dont remember what it was at that time. In my opinion its a very noble way to spread awareness. The other related software that I heard a few months back was Blackle - Energy Saving Search, which at the time of writing this blog claims to have saved 187,619.780 Watt hours of energy.

Wordweb is a free English thesaurus and dictionary for Windows, and can be used to look up words from within almost any program in just one click. You just select the text in your document or the browser and just left-click on the WordWeb icon on your task bar and it opens up the dictionary entry. In my opinion it is a must have thing for your PC.

3 comments ( 1099 views )   |  0 trackbacks   |  permalink   |   ( 3 / 67 )
Recently learned vi tricks : Search a file from inside vi 
Wednesday, September 5, 2007, 07:01 AM - Tips and Tricks
vi (or vim) they say is very powerful. I wonder sometimes : "Why is everything that is supposed to be powerful has remained unexplored by me?"

Though I prefer xemacs more than vi but end up using vi many times. I recently learned that I could find a file from inside vi. Many time we do a #include "xyz.h" in our C/C++ programs and we want to jump to that file directly. Move your cursor over the file name and type [Esc]gf to open that file right into your vi. It is not necessary for the file to be in #include. It could be anywhere and its not C/C++ specific.

The way it works is vi searches for the file in the path variable. This is not the PATH environmental variable. This is a vim specific option which generally defaults to .,/usr/local/include,/usr/include/. It searches your currently directly fist and then the default system include dirs.

You can add your own search able dirs to the path variable. If you want to include /home/shuva/include or ./include (meaning the include dir from your current working dir) you can set the path option like this:

:set path+=/home/shuva/include,./include

Dont ask me how to go back to the file you have been editing. I don't know and if you find it please write it up in the comments section below. I will be thankful.

If you want to explore more on smart vim tricks read the Vim documentation at sourceforge..
3 comments ( 205 views )   |  0 trackbacks   |  permalink   |   ( 3 / 52 )
Scenario 1/N: The program crashes but not while debugging.  
Monday, September 3, 2007, 08:51 AM - Programming
The program crashes with a bad segmentation fault.
You try hard looking at the code and run over it many times and dont see the error so easily.
So you attach your favorite debugger and step through it and it does not crash.


For a developer, this scenario is very irritating. You become almost helpless when the tools that are supposed to detect flaws in your code dont.

There are many reasons why a program does not crash in your debugger. Today I will demonstrate with an example one of the "N" reasons why this could happen.

A little basics:
A Segmentation fault (SIGSEGV) occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed.

It is possible that you or your debugger performed certain actions that has made a memory location readable or writable. Once this happens, then the code which used to seg-fault will run smoothly user the process space of the debugger. When you start a debugger like gdb, you have the ability to read data from any memory that you can access, provided you as a user has permission to do so.

The program you wrote must not have set permissions to access certain memory areas and may be trying to read from that memory.

Our example today is based on two processes, one writer and the other reader and they use POSIX shared memory to pass a message to the other.

The writer creates a shared memory segment. If it exists, it deletes it and creates a new segment. It then attaches to it, write a few bytes of data and detaches.

The reader attaches to the shared memory and tries to read the data and print. it then detaches and destroys the segment.

Thats all our program does. Below is the code straight from my build-box. You can simple copy and compile using the Makefile below. Discussion follows below ....


Code:
------------------------------------------------------------
/* myshm.h */
#ifndef SHM_H
#define SHM_H

#define MY_SHARED_MEM_NAME "/my_shared_mem_name"
#define MY_SHARED_MEM_SIZE 1024 //1 kb
#define READER 0
#define WRITER 1

void* Attach(int rw_flag);
void Detach();
void Destroy();
void Write();
void Read();

#endif


----------------------------------------------------------

/* myshm.c */

#include <stdio.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include "myshm.h"

void* mem_start = NULL;

void* Attach(int rw_flag) {
int ret = 0;
int fd = 0;
int shmExists = 0;

if (rw_flag == READER) {
fd = shm_open(MY_SHARED_MEM_NAME, O_RDWR ,S_IRWXU | S_IRWXG);
if (fd == -1) {
printf("Shared memory does not
exist..\n");
return NULL;
}
}

if (rw_flag == WRITER) {
fd = shm_open(MY_SHARED_MEM_NAME, O_RDWR | O_CREAT | O_EXCL, S_IRWXU | S_IRWXG);
if ((fd == -1) && (errno == EEXIST)) {
Destroy();
fd = shm_open(MY_SHARED_MEM_NAME,
O_RDWR | O_CREAT,
S_IRWXU | S_IRWXG);
if (fd == -1) {
return NULL;
}
}
} else if (fd == -1) {
return NULL;
}

if (rw_flag == WRITER) {
ret = ftruncate(fd, MY_SHARED_MEM_SIZE);
if (ret == -1) {
return NULL;
}
}

mem_start = mmap(0, MY_SHARED_MEM_SIZE, PROT_WRITE, MAP_SHARED, fd, 0);
if (mem_start == MAP_FAILED) {
return NULL;
}

ret = close(fd);
if (ret == -1) {
return NULL;
}

printf("Attached to shared memory at:%p\n",mem_start);

return mem_start;

}

void Detach() {
printf("Detaching...\n");
munmap(mem_start, MY_SHARED_MEM_SIZE);
return;
}

void Destroy() {
printf("Destroying shared memory..\n");
shm_unlink(MY_SHARED_MEM_NAME);
}

void Write() {
printf("Writing into shared memory..\n");
char* data = "NETOTTO";
memcpy(mem_start, (void*)data, 8);
return;
}

void Read() {
printf("Reading from shared memory..\n");
char data[8];
memcpy(data, mem_start, 8);
printf("Data is: %s\n", data);
return;
}


-----------------------------------------------------------

/* Writer.c */

#include <stdio.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <errno.h>
#include "myshm.h"

int main() {

int ret = 0;
if (Attach(WRITER) == NULL) {
perror("Error attaching to shared memory\n");
exit(1);
}
Write();
Detach();
return 0;
}



------------------------------------------------------------
/* reader.c */
#include <stdio.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <errno.h>
#include "myshm.h"
int main() {

int ret = 0;
if (Attach(READER) == NULL) {
perror("Error attaching to shared memory\n");
return(1);
}
Read();
Detach();
Destroy();
return 0;
}


-------------------------------------------------------------
/* Makefile */
default: all

all: writer reader

writer: myshm.o writer.o
g++ -g myshm.o writer.o -lrt -o writer

reader: myshm.o reader.o
g++ -g myshm.o reader.o -lrt -o reader

myshm.o: myshm.h myshm.c
gcc -c -g myshm.c

reader.o: reader.c
gcc -c -g reader.c

writer.o: writer.c
gcc -c -g writer.c

clean:
rm -f *.o reader writer


-----------------------------------------------------------

This is what happens when you run the writer followed by the reader.

[root@shuvavmrhel ]# make
gcc -c -g myshm.c
gcc -c -g writer.c
g++ -g myshm.o writer.o -lrt -o writer
gcc -c -g reader.c
g++ -g myshm.o reader.o -lrt -o reader

[root@shuvavmrhel ]# ./writer
Attached to shared memory at:0xb7fff000
Writing into shared memory..
Detaching...

[root@shuvavmrhel ]# ./reader
Attached to shared memory at:0xb7fff000
Reading from shared memory..
Segmentation fault
[root@shuvavmrhel ]#

The core dump file would suggest that the segmentation error in question is coming from the function Read():myshm.c at the memcpy() statement as shown below:

void Read() {
printf("Reading from shared memory..\n");
char data[8];
memcpy(data, mem_start, 8);
printf("Data is: %s\n", data);
return;
}

It is obvious that for some reason we are not allowed to read from the memory pointed by mem_start. If you run gdb and reach this line and try to access the memory pointed to by mem_start, it would display as follows:

81 memcpy(data, mem_start, 8);
(gdb) x/2 mem_start
0xb7fff000: 0x4f54454e 0x004f5454
(gdb) n
82 printf("Data is: %s\n", data);
(gdb) n
Data is: NETOTTO
84 }


You can now proceed with the gdb session. The memcpy works and we can see the data string "NETOTTO" printed for us.

No segmentation fault.

This is because when the reader memory mapped the shared memory into the process space, it did so with only the PROT_WRITE flag and not PROT_READ flag.

mem_start = mmap(0, MY_SHARED_MEM_SIZE, PROT_WRITE, MAP_SHARED, fd, 0);

The correct statement should have been

mem_start = mmap(0, MY_SHARED_MEM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

In gdb however, since we accessed the memory using the x/2 gdb-command, gdb acquired the read permissions and effectively the rest of our program which is running in the same space got the read permission for that memory segment. So it does not fail.

If we dont use the x/2 command in gdb, we would get the fault in gdb too.

This is a very important thing that I have learned and I am writing it here so that I dont waste another half a day scratching my head to figure out what went wrong.

Thoughts?
1 comment ( 176 views )   |  0 trackbacks   |  permalink   |   ( 2.9 / 65 )

<<First <Back | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | Next> Last>>