Summary
This is part 1 in a proof of concept serious involving the creation of a RAID 1 iSCSI Target using OpenFiler 2.13 and Vmware Server 2. We will purposely fail one of the virtual disks in the array rebuild the array and verify the data. In part one of the series we will create the Raid 1 array. In subsequent parts we will create an ISCSI Target, connect Windows Vista using iSCSI Initiator and simulate RAID 1 drive failure and recovery. The OpenFiler vmware appliance is free to download and use. The installation of both Vmware Server 2 and OpenFiler 2.13 vmware appliance will not be covered here.
Create VMware virtual disks
From the VMware Server 2 web administration create two 50 MB disks for the OpenFiler VMware guest accepting the VMware defaults.
Create Raid Partitions
As seen in Figure 1, navigate to openfiler > Volumes > Block Devices and select the first of our newly created disks /dev/sdb.
FIGURE 1: opefiler > Volumes > Block Devices
Create a RAID array partition by selecting Partition Type: “RAID array member” for the entire cylinder range (default) and clicking “Create”. See Figure 2. The resulting RAID partition should like as seen in Figure 3. Repeat the previous steps to create a RAID partition for /dev/sdc
FIGURE 2: opefiler > Volumes > Block Devices > /dev/sdb
FIGURE 3: openfiler > Volumes > Block Devices > /dev/sdb
Create New Raid 1 Array
Once the two raid devices have been created navigate to openfiler > Volumes > Software Raid as seen in Figure 4 below. Select RAID-1 from the drop down menu, leave the chunk size at default, select the two raid devices as seen in Figure 4 and click “Add array”. The resulting raid array information will be displayed as seen in Figure 5.
Figure 4: openfiler > Volumes > Software Raid
Figure 5: openfiler > Volumes > Software Raid
Create New Volume Group
Navigate to openfiler > Volumes > Volume Groups and create the new volume group “volgroupraid001”. If this is not your preferred volume group naming convention, change it to your liking. After entering your “Volume group name”, select our newly created Raid 1 volume /dev/md0 and click “Add volume group” as seen in Figure 6. The resulting Volume Group is displayed as seen in Figure 7.
Figure 6: openfile > Volumes > Volume Groups
Figure 7: openfiler > Volumes > Volume Groups
Create New Volume
Navigate to openfiler > Volume>Add Volume select our “volgroupraid001” volume group, enter the name our new volume “volraid001”, fill in a description, enter the Required Space” (32MB) and be sure to select the proper “Filesystem Type” of iSCSI. Click “Create” when ready. See Figure 8 below. The resulting Volume Group will be as seen in Figure 9.
Figure 8: openfiler > Volume > Add Volume
Figure 9: openfiler > Volumes > Manager Volumes
In our next section we will create the OpenFiler iSCSI Target using our newly created RAID 1 volume.
Wednesday, June 08, 2011
OpenFiler 2.99 - Attempted to Create Software Raid 1 Array - Failed...
Heres the code you need to get RAID1 working on Openfiler 2.99:
You need to type the following commands into the shell.
Code:
conary update mdadm=openfiler.rpath.org@rpl:devel/2.6.4-0.2-1
This will install the correct mdadm files, once installed type the next command in.
Code:
ln -s /sbin/lvm /usr/sbin/lvm
This ensures that the GUI is populated correctly.
This will then allow you to create all of the software RAID types without issue.
I extracted this info from here: http://www.everything-virtual.com/?p=349
You need to type the following commands into the shell.
Code:
conary update mdadm=openfiler.rpath.org@rpl:devel/2.6.4-0.2-1
This will install the correct mdadm files, once installed type the next command in.
Code:
ln -s /sbin/lvm /usr/sbin/lvm
This ensures that the GUI is populated correctly.
This will then allow you to create all of the software RAID types without issue.
I extracted this info from here: http://www.everything-virtual.com/?p=349
Friday, April 01, 2011
Dionea - Honeypot
Copy N Paste from
http://networkdefense.com.au/2010/06/12/first-experiences-with-dionaea/
After a lot of reading, a few very late nights, and a fair bit of indecision I decided to install Dionaea. It was down to mwcollectd or Dionaea as my next choice for a 30 day test, but I had quite a few issues getting mwcollectd running properly. I think this is mostly due to my lack of experience compiling stuff in linux, and also not understanding what to do when things fail or don't compile as expected. So I moved on and began to follow Markus' extensive Dionaea install documentation.
My first few attempts failed, in epic fashion. Initially for some unknown reason I decided to install Python 3 from testing... even though the documentation says to compile it. This brought up issues with sqlite3, again frustrating but a good learning experience. Follow the doco! In the end I had to make a slight modification to the ./configure script when compiling Dionaea, as Cython was not being found. Other than that the install was very smooth. I installed Dionaea under Debian 64bit, chose KDE graphical install and left the 'Standard System' and 'Desktop Environment' options checked.
I thought it would be a good idea to post the steps I took to install Dionaea, not sure if it is of use to anyone else. It's basically just a rehash of Markus' documentation.
1. Stuff from APT
apt-get install libglib2.0-dev libssl-dev libcurl4-openssl-dev libreadline-dev libsqlite3-dev python-dev libtool automake autoconf build-essential subversion git-core flex bison pkg-config
2. gettext / glib
apt-get install gettext
wget http://ftp.gnome.org/pub/gnome/sources/glib/2.20/glib-2.20.4.tar.bz2
tar xfj glib-2.20.4.tar.bz2
rm glib-2.20.4.tar.bz2
cd glib-2.20.4/
./configure --prefix=/opt/dionaea
make
make install
cd ..
3. liblcfg
git clone git://git.carnivore.it/liblcfg.git liblcfg
cd liblcfg/code
autoreconf -vi
./configure --prefix=/opt/dionaea
make install
cd /usr/local/src
4. libemu
git clone git://git.carnivore.it/libemu.git libemu
cd libemu
autoreconf -vi
./configure --prefix=/opt/dionaea
make install
cd ..
5. libnl (optional)
git clone git://git.kernel.org/pub/scm/libs/netlink/libnl.git
cd libnl
autoreconf -vi
export LDFLAGS=-Wl,-rpath,/opt/dionaea/lib
./configure --prefix=/opt/dionaea
make
make install
cd ..
6. libev
wget http://dist.schmorp.de/libev/Attic/libev-3.9.tar.gz
tar xfz libev-3.9.tar.gz
rm libev-3.9.tar.gz
cd libev-3.9
./configure --prefix=/opt/dionaea
make install
cd ..
7. Cython
wget http://cython.org/release/Cython-0.12.1.tar.gz
tar xfz Cython-0.12.1.tar.gz
rm Cython-0.12.1.tar.gz
cd Cython-0.12.1
python setup.py build
python setup.py install
8. sqlite3
apt-get install sqlite3
9. Python 3.1.2
wget http://python.org/ftp/python/3.1.2/Python-3.1.2.tgz
tar xfz Python-3.1.2.tgz
rm Python-3.1.2.tgz
cd Python-3.1.2/
./configure --enable-shared --prefix=/opt/dionaea --with-computed-gotos \
--enable-ipv6 LDFLAGS="-Wl,-rpath=/opt/dionaea/lib/"
make
make install
cd ..
10. libxml2-dev
apt-get install libxml2-dev
11. libxslt1-dev
aptitude install libxslt1-dev
12. lxml
wget http://codespeak.net/lxml/lxml-2.2.6.tgz
tar xfz lxml-2.2.6.tgz
rm lxml-2.2.6.tgz
cd lxml-2.2.6
/opt/dionaea/bin/2to3 -w src/lxml/html/_diffcommand.py
/opt/dionaea/bin/2to3 -w src/lxml/html/_html5builder.py
/opt/dionaea/bin/python3 setup.py build
/opt/dionaea/bin/python3 setup.py install
cd ..
13. udns
wget http://www.corpit.ru/mjt/udns/udns_0.0.9.tar.gz
tar xfz udns_0.0.9.tar.gz
rm udns_0.0.9.tar.gz
cd udns-0.0.9/
./configure
make shared
cp udns.h /opt/dionaea/include/
cp *.so* /opt/dionaea/lib/
cd /opt/dionaea/lib
ln -s libudns.so.0 libudns.so
cd /usr/local/src
14. Curl & C-ares
wget http://c-ares.haxx.se/c-ares-1.7.3.tar.gz
tar xfz c-ares-1.7.3.tar.gz
cd c-ares-1.7.3
./configure --prefix=/opt/dionaea
make
make install
cd ..
wget http://curl.haxx.se/download/curl-7.20.0.tar.bz2
tar xfj curl-7.20.0.tar.bz2
rm curl-7.20.0.tar.bz2
cd curl-7.20.0
./configure --prefix=/opt/dionaea
make
make install
cd ..
15. libpcap
wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
tar xfz libpcap-1.1.1.tar.gz
rm libpcap-1.1.1.tar.gz
cd libpcap-1.1.1
./configure --prefix=/opt/dionaea
make
make install
cd ..
16. Dionaea (with my own changes on the Cython line from '/usr/local/bin' to '/usr/bin')
git clone git://git.carnivore.it/dionaea.git dionaea
cd dionaea
autoreconf -vi
./configure --with-lcfg-include=/opt/dionaea/include/ \
--with-lcfg-lib=/opt/dionaea/lib/ \
--with-python=/opt/dionaea/bin/python3.1 \
--with-cython-dir=/usr/bin \
--with-udns-include=/opt/dionaea/include/ \
--with-udns-lib=/opt/dionaea/lib/ \
--with-emu-include=/opt/dionaea/include/ \
--with-emu-lib=/opt/dionaea/lib/ \
--with-gc-include=/usr/include/gc \
--with-ev-include=/opt/dionaea/include \
--with-ev-lib=/opt/dionaea/lib \
--with-nl-include=/opt/dionaea/include \
--with-nl-lib=/opt/dionaea/lib/ \
--with-curl-config=/opt/dionaea/bin/ \
--with-pcap-include=/opt/dionaea/include \
--with-pcap-lib=/opt/dionaea/lib/ \
--with-glib=/opt/dionaea
make
make install
Running Dionaea
cd /opt/dionaea/bin/
./dionaea -l all,-debug -L '*'
Within moments of launching Dionaea connection attempts began pouring in, mostly rejected attempts. After around 30 minutes the first sample was received along with some interesting colours flying past - looking forward to going through the logs later this evening. Now all that's left to do is get the p0f ihandler turned on. So far things are looking promising.
Getting Dionaea up and running has been a great experience. I've learned a lot about compiling, dependencies, issues, and Debian in general. I'm very keen to see what kind of information it can produce over the coming month.
- Cooper
*update: 27th November 2010 - Updated Dionaea Install Instructions
http://networkdefense.com.au/2010/06/12/first-experiences-with-dionaea/
After a lot of reading, a few very late nights, and a fair bit of indecision I decided to install Dionaea. It was down to mwcollectd or Dionaea as my next choice for a 30 day test, but I had quite a few issues getting mwcollectd running properly. I think this is mostly due to my lack of experience compiling stuff in linux, and also not understanding what to do when things fail or don't compile as expected. So I moved on and began to follow Markus' extensive Dionaea install documentation.
My first few attempts failed, in epic fashion. Initially for some unknown reason I decided to install Python 3 from testing... even though the documentation says to compile it. This brought up issues with sqlite3, again frustrating but a good learning experience. Follow the doco! In the end I had to make a slight modification to the ./configure script when compiling Dionaea, as Cython was not being found. Other than that the install was very smooth. I installed Dionaea under Debian 64bit, chose KDE graphical install and left the 'Standard System' and 'Desktop Environment' options checked.
I thought it would be a good idea to post the steps I took to install Dionaea, not sure if it is of use to anyone else. It's basically just a rehash of Markus' documentation.
1. Stuff from APT
apt-get install libglib2.0-dev libssl-dev libcurl4-openssl-dev libreadline-dev libsqlite3-dev python-dev libtool automake autoconf build-essential subversion git-core flex bison pkg-config
2. gettext / glib
apt-get install gettext
wget http://ftp.gnome.org/pub/gnome/sources/glib/2.20/glib-2.20.4.tar.bz2
tar xfj glib-2.20.4.tar.bz2
rm glib-2.20.4.tar.bz2
cd glib-2.20.4/
./configure --prefix=/opt/dionaea
make
make install
cd ..
3. liblcfg
git clone git://git.carnivore.it/liblcfg.git liblcfg
cd liblcfg/code
autoreconf -vi
./configure --prefix=/opt/dionaea
make install
cd /usr/local/src
4. libemu
git clone git://git.carnivore.it/libemu.git libemu
cd libemu
autoreconf -vi
./configure --prefix=/opt/dionaea
make install
cd ..
5. libnl (optional)
git clone git://git.kernel.org/pub/scm/libs/netlink/libnl.git
cd libnl
autoreconf -vi
export LDFLAGS=-Wl,-rpath,/opt/dionaea/lib
./configure --prefix=/opt/dionaea
make
make install
cd ..
6. libev
wget http://dist.schmorp.de/libev/Attic/libev-3.9.tar.gz
tar xfz libev-3.9.tar.gz
rm libev-3.9.tar.gz
cd libev-3.9
./configure --prefix=/opt/dionaea
make install
cd ..
7. Cython
wget http://cython.org/release/Cython-0.12.1.tar.gz
tar xfz Cython-0.12.1.tar.gz
rm Cython-0.12.1.tar.gz
cd Cython-0.12.1
python setup.py build
python setup.py install
8. sqlite3
apt-get install sqlite3
9. Python 3.1.2
wget http://python.org/ftp/python/3.1.2/Python-3.1.2.tgz
tar xfz Python-3.1.2.tgz
rm Python-3.1.2.tgz
cd Python-3.1.2/
./configure --enable-shared --prefix=/opt/dionaea --with-computed-gotos \
--enable-ipv6 LDFLAGS="-Wl,-rpath=/opt/dionaea/lib/"
make
make install
cd ..
10. libxml2-dev
apt-get install libxml2-dev
11. libxslt1-dev
aptitude install libxslt1-dev
12. lxml
wget http://codespeak.net/lxml/lxml-2.2.6.tgz
tar xfz lxml-2.2.6.tgz
rm lxml-2.2.6.tgz
cd lxml-2.2.6
/opt/dionaea/bin/2to3 -w src/lxml/html/_diffcommand.py
/opt/dionaea/bin/2to3 -w src/lxml/html/_html5builder.py
/opt/dionaea/bin/python3 setup.py build
/opt/dionaea/bin/python3 setup.py install
cd ..
13. udns
wget http://www.corpit.ru/mjt/udns/udns_0.0.9.tar.gz
tar xfz udns_0.0.9.tar.gz
rm udns_0.0.9.tar.gz
cd udns-0.0.9/
./configure
make shared
cp udns.h /opt/dionaea/include/
cp *.so* /opt/dionaea/lib/
cd /opt/dionaea/lib
ln -s libudns.so.0 libudns.so
cd /usr/local/src
14. Curl & C-ares
wget http://c-ares.haxx.se/c-ares-1.7.3.tar.gz
tar xfz c-ares-1.7.3.tar.gz
cd c-ares-1.7.3
./configure --prefix=/opt/dionaea
make
make install
cd ..
wget http://curl.haxx.se/download/curl-7.20.0.tar.bz2
tar xfj curl-7.20.0.tar.bz2
rm curl-7.20.0.tar.bz2
cd curl-7.20.0
./configure --prefix=/opt/dionaea
make
make install
cd ..
15. libpcap
wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
tar xfz libpcap-1.1.1.tar.gz
rm libpcap-1.1.1.tar.gz
cd libpcap-1.1.1
./configure --prefix=/opt/dionaea
make
make install
cd ..
16. Dionaea (with my own changes on the Cython line from '/usr/local/bin' to '/usr/bin')
git clone git://git.carnivore.it/dionaea.git dionaea
cd dionaea
autoreconf -vi
./configure --with-lcfg-include=/opt/dionaea/include/ \
--with-lcfg-lib=/opt/dionaea/lib/ \
--with-python=/opt/dionaea/bin/python3.1 \
--with-cython-dir=/usr/bin \
--with-udns-include=/opt/dionaea/include/ \
--with-udns-lib=/opt/dionaea/lib/ \
--with-emu-include=/opt/dionaea/include/ \
--with-emu-lib=/opt/dionaea/lib/ \
--with-gc-include=/usr/include/gc \
--with-ev-include=/opt/dionaea/include \
--with-ev-lib=/opt/dionaea/lib \
--with-nl-include=/opt/dionaea/include \
--with-nl-lib=/opt/dionaea/lib/ \
--with-curl-config=/opt/dionaea/bin/ \
--with-pcap-include=/opt/dionaea/include \
--with-pcap-lib=/opt/dionaea/lib/ \
--with-glib=/opt/dionaea
make
make install
Running Dionaea
cd /opt/dionaea/bin/
./dionaea -l all,-debug -L '*'
Within moments of launching Dionaea connection attempts began pouring in, mostly rejected attempts. After around 30 minutes the first sample was received along with some interesting colours flying past - looking forward to going through the logs later this evening. Now all that's left to do is get the p0f ihandler turned on. So far things are looking promising.
Getting Dionaea up and running has been a great experience. I've learned a lot about compiling, dependencies, issues, and Debian in general. I'm very keen to see what kind of information it can produce over the coming month.
- Cooper
*update: 27th November 2010 - Updated Dionaea Install Instructions
Friday, March 25, 2011
Metasploit Framework
Installation on Ubuntu Linux
The Metasploit Framework is well-supported on the Ubuntu platform. The following instructions should also apply to Kubuntu, Xubuntu, and Debian.
If these instructions do not work for your version of Ubuntu, please try the Generic Linux instructions instead.
Dependencies
Install the Ruby dependencies:
$ sudo apt-get install ruby libopenssl-ruby libyaml-ruby libdl-ruby libiconv-ruby libreadline-ruby irb ri rubygems
Install the Subversion client:
$ sudo apt-get install subversion
In order to build the native extensions (pcaprub, lorcon2, etc), the following packages need to be installed:
$ sudo apt-get install build-essential ruby-dev libpcap-dev
Metasploit Framework
Once the dependencies have been installed, download the Unix tarball from the download page and run the following commands:
$ tar xf framework-3.X.tar.gz
$ sudo mkdir -p /opt/metasploit3
$ sudo cp -a msf3/ /opt/metasploit3/msf3
$ sudo chown root:root -R /opt/metasploit3/msf3
$ sudo ln -sf /opt/metasploit3/msf3/msf* /usr/local/bin/
When you've completed this step, you should have a working installation and be able to run modules, pivot through compromised systems, and use most of the Metasploit Framework's features. The following optional installation steps will give you extra functionality.
Database Configuration (optional)
Now that the framework is installed, you'll want to configure a database connection, and enable the Metasploit Framework to connect to it:
For postgres, see postgres_setup (recommended)
For mysql, see mysql_setup
For sqlite, see sqlite_setup (not supported!!).
Extensions (optional)
The Metasploit Framework includes a few native Ruby extensions that must be compiled in order to use certain types of modules.
To enable raw socket modules:
$ sudo apt-get install libpcap-dev
$ sudo bash
# cd /opt/metasploit3/msf3/external/pcaprub/
# ruby extconf.rb
# make && make install
To enable WiFi modules:
$ sudo bash
# cd /opt/metasploit3/msf3/external/ruby-lorcon2/
# svn co http://802.11ninja.net/svn/lorcon/trunk lorcon2
# cd lorcon2
# ./configure --prefix=/usr && make && make install
# cd ..
# ruby extconf.rb
# make && make install
Updates
The Metasploit Framework is updated daily with the latest exploits, payloads, features, and bug fixes. To update your installation of the Metasploit Framework:
$ sudo svn update /opt/metasploit3/msf3/
This can also be installed into the root user's crontab:
$ sudo crontab -e -u root # enter the line below
1 * * * * /usr/bin/svn update /opt/metasploit3/msf3/ >> /var/log/msfupdate.log 2>&1
The Metasploit Framework is well-supported on the Ubuntu platform. The following instructions should also apply to Kubuntu, Xubuntu, and Debian.
If these instructions do not work for your version of Ubuntu, please try the Generic Linux instructions instead.
Dependencies
Install the Ruby dependencies:
$ sudo apt-get install ruby libopenssl-ruby libyaml-ruby libdl-ruby libiconv-ruby libreadline-ruby irb ri rubygems
Install the Subversion client:
$ sudo apt-get install subversion
In order to build the native extensions (pcaprub, lorcon2, etc), the following packages need to be installed:
$ sudo apt-get install build-essential ruby-dev libpcap-dev
Metasploit Framework
Once the dependencies have been installed, download the Unix tarball from the download page and run the following commands:
$ tar xf framework-3.X.tar.gz
$ sudo mkdir -p /opt/metasploit3
$ sudo cp -a msf3/ /opt/metasploit3/msf3
$ sudo chown root:root -R /opt/metasploit3/msf3
$ sudo ln -sf /opt/metasploit3/msf3/msf* /usr/local/bin/
When you've completed this step, you should have a working installation and be able to run modules, pivot through compromised systems, and use most of the Metasploit Framework's features. The following optional installation steps will give you extra functionality.
Database Configuration (optional)
Now that the framework is installed, you'll want to configure a database connection, and enable the Metasploit Framework to connect to it:
For postgres, see postgres_setup (recommended)
For mysql, see mysql_setup
For sqlite, see sqlite_setup (not supported!!).
Extensions (optional)
The Metasploit Framework includes a few native Ruby extensions that must be compiled in order to use certain types of modules.
To enable raw socket modules:
$ sudo apt-get install libpcap-dev
$ sudo bash
# cd /opt/metasploit3/msf3/external/pcaprub/
# ruby extconf.rb
# make && make install
To enable WiFi modules:
$ sudo bash
# cd /opt/metasploit3/msf3/external/ruby-lorcon2/
# svn co http://802.11ninja.net/svn/lorcon/trunk lorcon2
# cd lorcon2
# ./configure --prefix=/usr && make && make install
# cd ..
# ruby extconf.rb
# make && make install
Updates
The Metasploit Framework is updated daily with the latest exploits, payloads, features, and bug fixes. To update your installation of the Metasploit Framework:
$ sudo svn update /opt/metasploit3/msf3/
This can also be installed into the root user's crontab:
$ sudo crontab -e -u root # enter the line below
1 * * * * /usr/bin/svn update /opt/metasploit3/msf3/ >> /var/log/msfupdate.log 2>&1
Wednesday, February 02, 2011
How To Delete Remembered Network Passwords In Windows
A user asked in the forums about how to delete a cached password that is stored in Windows. When we want to access another computer (specifically Windows), sometimes if the remote computer requires a password to access its resources like files and printers, we have to give the username and password once and then it remains in the Windows Cache until it is restarted or logged off. And if we check the remember password option, then it remains in even after Windows restart. Here’s the method to delete cached Windows Network passwords:
Go to Start Menu –> Run –> control userpasswords2 and press Enter.
User Accounts Dialog Box will appear, Go to Advance Tab and Click on the Manage Password Button. In Stored User Names and Password press the Remove Button and Remove all users information that you want to delete.
Go to Start Menu –> Run –> control userpasswords2 and press Enter.
User Accounts Dialog Box will appear, Go to Advance Tab and Click on the Manage Password Button. In Stored User Names and Password press the Remove Button and Remove all users information that you want to delete.
Wednesday, November 24, 2010
Password Management Best Practices
This document describes and justifies password management best practices as applied in medium to large organizations. It offers reasoned guidance to IT decision makers when they set security policy and design network infrastructure that includes passwords.
The guidance in this document is focused on how to best manage user passwords. It is not intended to address the special challenges and techniques that arise when managing privileged passwords, that belong to administrators, service accounts, etc.
Look for the figure marks throughout this document to find best practices.
User authentication and passwords
(1)
Definitions
* Identification
The unique identifier that a user types to sign into a system or application is that user's login ID on that system.
* Authentication
Authentication is a process by which a user proves his identity to a system -- normally when logging in.
* Authentication factor
An authentication factor is something a user presents to a system in order to prove his identity. It may be something he (and hopefully only he) knows, or proof of possession of a physical object, or a measurement of some physical characteristic (biometric) of the living human user. In other words, something the user knows, or something he has, or something he is.
* Multi-factor authentication
Multi-factor authentication means authentication using multiple factors . For example, a user might sign into a system with a combination of two things he knows, or a combination of something he knows and something he has, or perhaps something he knows, something he has and something he is.
The premise is that adding authentication factors makes it more difficult for a would-be attacker to simulate a legitimate authentication and consequently impersonate a legitimate user.
* Strong authentication
Strong authentication refers to an authentication process which is difficult to simulate. It may be based on use of multiple authentication factors or use of a single but hard-to-spoof authentication factor .
Authentication technologies
Authentication technologies may be categorized as follows:
Authentication Factor
Description
Example
Secrets: Something you know.
Secret information known only the user.
A password or PIN.
Tokens: Something you have.
A physical device possessed only be the user.
A one time password (OTP) token or smart card.
Biometrics: Something you are.
A unique, measurable characteristic of the user.
Voice print verification, fingerprint, vein pattern, retina or iris scan.
Generally, it is more secure but less convenient to use multiple forms of authentication -- e.g., a one time password token combined with a password or PIN.
These types of authentication may be further characterized as follows:
Characteristic
Secrets
Tokens
Biometrics
Reliable identification? Good Very good Excellent
Requires client-side hardware No Sometimes Yes
Requires client-side software No Sometimes Yes
Typical deployment cost/user 0 $50 $100
Works with legacy systems Yes No No
Due to cost and compatibility with legacy systems, the most popular form of user authentication continues to be a secret password.
Moreover, as non-password authentication technologies are deployed, they are usually combined with passwords to improve their security. For example, tokens are secure -- unless they are stolen, in which case the person who stole the token can impersonate the legitimate user. This is easily remedied by requiring the user to sign into systems with the OTP displayed on a token plus a password or PIN, which a thief would not know.
The remainder of this document discusses how to best manage passwords, to maximize security and minimize cost of ownership. The guidelines here apply primarily to passwords used as a single authentication factor, but can also be applied to passwords used as a second authentication factor, in conjunction with biometrics, tokens or smart cards.
Security threats
(2)
Passwords are simply secret words or phrases. They can be compromised in many ways:
* Users may write them down or share them, so that they are no longer really secret.
* Passwords can be guessed, either by a person or a program designed to try many possibilities in rapid succession.
* Passwords may be transmitted over a network either in plaintext or encoded in a way which can be readily converted back to plaintext.
* Passwords may be stored on a workstation, server or backup media in plaintext or encoded in a way which can be readily converted back to plaintext.
Each of these vulnerabilities make it easier for someone to acquire the password value and consequently pose as the user whose identity the password protects.
Conversely, if passwords are managed securely by users and if password systems are constructed so as to prevent brute-force attacks and inspection or decryption of passwords in transit and in storage, then passwords can actually be quite secure. This document will describe some of the mechanisms for securing passwords.
Human factors
(3)
Users in a large organization frequently have many passwords, each protecting their account on a different system or application. Users are people, not machines, so their ability to securely manage passwords is intrinsically limited. In particular, it is hard for most people to remember:
* Complicated passwords.
* Many different passwords.
* Passwords that change frequently.
* Passwords for systems that are used infrequently.
Without these constraints, password security would not be a problem and there would be no market for other authentication technologies. For example, if every password was changed every day, was remembered perfectly without being written down and consisted of 100 randomly chosen letters and digits, there would really be no need for authentication technologies other than passwords.
Effective password management is therefore taken to mean password management that is secure, user friendly and supportable within the confines of both technology and human behavior.
When people have trouble remembering their passwords, they usually resort to one or more of the following:
* Write down their passwords -- and reduce the security of systems to the security of their physical building, desk or wallet.
* Forget their passwords -- and require frequent assistance from an IT help desk to reset it.
* Use very simple, easily compromised passwords.
* Reuse old passwords as often as possible.
Clearly, sound password management practices must take into consideration human limitations, to reduce the frequency of these insecure practices.
Composing hard-to-guess passwords
(4)
As outlined in (2), one of the weaknesses of passwords is that they can be guessed. While a human may give up after ten or a hundred guesses, software s available to automate the guessing process and try millions of possible passwords per second:
* L0phtCrack: http://www.l0phtcrack.com/ for Windows.
* John the Ripper: http://www.openwall.com/john/ for Windows, Mac OS X or Linux.
* Many others.
To combat password guessing attack, users should pick hard-to-guess passwords. One way to do this is to ensure that the set of all possible passwords is too large to search thoroughly and then to eliminate probable guesses, which an attacker might try first.
The number of possible password combinations is calculated by taking the number of legal characters in a password and raising that number to the number of characters in the password. The possibilities for some typical combinations are shown below:
Character set
5
6
7
8
9
10
0-9 1.00e05 1.00e06 1.00e07 1.00e08 1.00e09 1.00e10
a-z 1.19e07 3.09e08 8.03e09 2.09e11 5.43e12 1.41e14
a-z,0-9 6.05e07 2.18e09 7.84e10 2.82e12 1.02e14 3.66e15
a-z,0-9,3 punct 9.02e07 3.52e09 1.37e11 5.35e12 2.09e14 8.14e15
a-z,A-Z 3.80e08 1.98e10 1.03e12 5.35e13 2.78e15 1.45e17
a-z,A-Z,0-9 9.16e08 5.68e10 3.52e12 2.18e14 1.35e16 8.39e17
a-z,A-Z,0-9,32 punct 7.34e09 6.90e11 6.48e13 6.10e15 5.73e17 5.39e19
Users should choose their passwords from the widest possible set of characters, subject to the constraints of the systems where those passwords reside. For example, most mainframes do not distinguish between uppercase and lowercase and only allow three punctuation marks (fourth row in the table above).
The policy should be based on the smallest acceptable set of possible password values. This, in turn, depends on how fast an attacker can check if a possible password is valid; how much time an attacker has to attack a given password and how log we want the attacker's probability of success to be.
This is best illustrated with an example:
1. Assumptions:
1. Encrypted passwords are not available to an attacker and consequently passwords can only be guessed at a rate of 100/second (this number is high / conservative for an over-the-network attack).
2. An attacker can make an unlimited number of guesses without being detected (this is easy to fix).
3. Passwords are changed, at most, every 90 days.
2. Objective: the attacker's probability of success should be no more than 1%.
3. Technical constraints: passwords may only contain lowercase letters, uppercase letters and digits.
4. Calculation:
1. An attacker can make 90 x 24 x 60 x 60 x 100 = 777,600,000 guesses before a password will expire.
2. There should be 77,760,000,000 possible passwords -- about 8e10.
3. From the above table, a 7 character password is sufficient, so long as users don't pick easily guessed values (e.g., their name or a dictionary word).
In practice, assuming that encrypted passwords are not available to an attacker and that passwords cannot be captured or decrypted in transit, the following policy is a often reasonable:
* To ensure that the search space is sufficiently large:
o Passwords must be at least seven characters long.
o Passwords must contain at least one lowercase letter, at least one uppercase letter and at least one digit.
o If technically possible, passwords must contain at least one punctuation mark, so long as there are many (10 or more) available punctuation marks.
* To eliminate trivial passwords, passwords should not:
o Contain the user's name or login ID.
o Contain a dictionary word, in any language that users can reasonably be expected to know.
o More than two paired letters (e.g. abbcdde is valid, but abbbcdd is not).
Some of these rules merit further discussion, since a naive implementation of the rule can actually reduce password security. Consider the rule "password should not contain a dictionary word." The letters "a" and "I" are legitimate English words, and if the rule is enforced using a dictionary that contains these, then in effect we have reduced the set of available letters from 26 to 24. To avoid this sort of problem, rules of the form "shall not contain" should be fine-tuned:
* Ignore words with 3 or fewer characters, since including such words in a dictionary check may actually make passwords easier to guess, by eliminating too many legitimate password values.
* Consider dictionary words without regard to case. "Hello12" should not be a valid password, even if the dictionary contains "hello" but not "Hello".
Unicode and other non-Latin passwords
(5)
Most password composition rules focus on how passwords composed of Latin characters (i.e., "English language" letters), digits and punctuation marks are composed.
Unfortunately, English is the native language of no more than 400 million people and is spoken by no more than 1.5 billion people -- out of a global population of over 6.5 billion people. In other words, even if other European languages that use a similar character set are included, a focus on Latin characters ignores at least 2/3 of the world's population.
This not just an academic problem. Many organizations are global in nature and include users who speak a variety of languages. A system or application whose users reside around the world needs to enforce a password policy that makes sense for all of them, not just for those who happen to prefer English.
Password management for multi-lingual users is a broad subject, but following are some important considerations:
1. Most users, in most countries, have keyboards that include most Latin characters. This means that they are able to type passwords composed of "English" letters, even if they don't read or write the language.
2. Not every system or application supports non-Latin characters in the password field. When composing an enterprise password policy, it's important to consider the limitations on the password fields of in-scope systems and applications. Failing to do this can yield a policy that is relevant to only some systems.
3. In countries where Chinese, Japanese or Korean (CJK) is spoken, text input often involves a display component. For example, a Chinese user might type the pinyin representation of a character and the input software will display a list of matching characters. The user will then choose the desired character and start on the next character.
This pattern is normal for input of text in the CJK languages but is problematic for passwords since password input should not be visible to other people in the physical vicinity.
Most CJK users avoid this problem by choosing passwords that consist only of Latin characters -- something that may surprise native English speakers.
Some best practices follow from this discussion:
1. Encourage or require users to restrict their passwords to Latin characters, both for compatibility and to avoid input methods which display the characters users type.
2. Do use a dictionary lookup to ensure that new passwords are hard to guess, and do include dictionaries of non-English words represented in Latin character sets (e.g., Pinyin, etc.).
Changing and reusing passwords
(6)
Over time, passwords may be compromised in many ways, including:
* Users may share them with friends or coworkers.
* Users may write them down and they may subsequently be exposed.
* Passwords may be guessed, either by humans or software.
* The servers that store passwords may be compromised and their passwords acquired by an intruder (encrypted, hashed or plaintext).
* The networks over which passwords travel, between a user's workstation and the system into which the user signs in may be compromised, again leading to compromise of a password.
* Users may be tricked into revealing their passwords (phishing).
* The help desk may be tricked into giving an intruder a valid password (social engineering).
To limit the usefulness of passwords that have been compromised, a best practice is to change them regularly. A common rule in many organizations is to force users to change their passwords when they log in, every 60 or 90 days.
In general, users should be required to change their passwords regularly. The password expiry interval should not be longer than 90 days.
For the same reasons, users should not reuse old passwords, as they may already have been compromised. Many systems support this by recording some representation of old passwords and ensuring that users cannot change their password back to a previously used value.
When password history is enforced, users may figure out the number of passwords stored for this purpose. As this number is usually 10 or fewer, a user who would prefer to keep his password the same may make a series of consecutive password changes where the final password value is the same as the first one.
To defeat such "smart" users, some systems also enforce a password rule that limits the number of password changes that a user can make in any given day. By making the process of defeating password history take several days, users are discouraged from trying to reuse old passwords.
A better approach, though not available on all systems, is to simply maintain an unlimited number of entries in each user's password history. Since disk storage is inexpensive, this approach is practical on modern systems. With this approach, users can change their passwords as often as they like -- and still never be able to reuse old ones.
Keeping passwords secret
(7)
Passwords are intended to reliably differentiate between the authentic user and impostors. As such, they must be secrets -- known only to the user they identify.
Users frequently behave in ways that lead to password disclosure. In particular, users may:
* Choose passwords which are easily guessed -- so are not really secret.
* Share their passwords with coworkers, friends or family.
* Write down their passwords and place the written password near their computer or in a supposedly private place like a wallet.
A comprehensive password policy should explicitly forbid these behaviors and specify negative consequences to users who violate the policy.
To help users comply with an effective password policy, user friendly password management tools and processes should be provided. Key among such aids to users are password synchronization and single sign-on.
With either synchronized or automatically filled-in passwords, users have fewer passwords to remember so they are less likely to write down their passwords.
Intruder detection and lockout
(8)
Many systems can detect repeated attempts to sign into an account with incorrect passwords. A pattern of failed logins may be due to:
1. Typing problems. For example, the user may have the Caps Lock or Num Lock key enabled and not realize it.
2. A forgotten password.
3. The wrong password being used. For example, the user may be trying to sign into system A using the password for system B.
4. An intruder trying to sign into an account by guessing the legitimate user's password.
To deter the last of these, it's reasonable for a system that detects too many invalid attempts during a short period of time to lock out the user's account and prevent further attempts, at least for a while. This is called an intruder lockout.
Many systems include an "intruder lockout" feature. If N invalid attempts to login to the same account are made during an interval of Tdetect minutes, then the account is disabled for Tlockout minutes.
While this mechanism is effective against concerted attacks against a single account, it does nothing to prevent an intruder from simultaneously trying to guess the passwords of many users. A more sophisticated mechanism might extend this as follows: If M invalid login attempts are made from network address A, to any account, during an interval of Tdetect minutes, then the address A is disabled for Tlockout minutes.
This will deter intruders with access to just a single network device/address from which to carry out their attack.
Intruder lockout also has a down side -- it can be used to carry out a denial of service -- by systematically locking out many accounts, including administrator IDs.
Because of these fundamental limitations, the best practice is to combine several intruder lockout-related policies:
* Apply only to users, exempting at least one administrator login. This limits the scope of denial of service attacks.
* A compensating control is required here, such as requiring administrator IDs to have very complex passwords that are changed more frequently than user passwords. This way, they cannot be guessed (too hard) or locked out (feature not available).
* Apply a high threshold for intruder detection -- for example, 10 failed login attempts in 5 minutes. This prevents spurious lockouts caused by users who have trouble remembering or typing their own passwords.
* Automatically and quickly clear lockouts -- for example, after 10 or 15 minutes. This reduces the impact on legitimate users while continuing to significantly impair the ability of intruders to make bulk password guessing attacks.
Encrypting passwords in storage and transit
(9)
Passwords may be stored on user workstations or servers. They must be transmitted, in some form, from the user's workstation to a server when the user signs into systems and applications.
Most organizations are powerless to improve the manner in which existing infrastructure uses encryption to protect passwords. However, staff responsible for developing a new applications that include password authentication can and should take effective precautions, such as storing passwords using a well-known and trusted hashing algorithm such as SHA-256 or (somewhat less effective, but still infeasible to find a collision in 2010) SHA-1.
Passwords transmitted from a client device to a server are similarly subject to weaknesses in the protocol used by the relevant application. For example, Telnet and TN3270 are plaintext while SSH and SSL are strongly encrypted. Where password security is important and where one cannot trust the physical security of all communication media between a user and the systems he logs into, then additional mechanisms, such as IPSec should be considered to protect that communication.
Some client devices and applications cache passwords and automatically provide them to servers on behalf of users, as required. Cached passwords should also be cryptographically protected, but in this case encryption rather than hashing is required, since the password must be recoverable.
In some cases, the protocol provided by a vendor may encrypt passwords when they are used to login to a system, but not when a password change is transmitted. This happens with Oracle SQL*Net, for example. In these cases, if password management software is deployed, it is helpful for that software to implement its own encryption for password transmission, beyond that provided natively by the application vendor.
Synchronizing passwords
(10)
Password synchronization technology helps users to maintain the same password on two or more systems. This, in turn, makes it easier for users to remember their passwords, reducing the need to write down passwords or to call an IT help desk to request a new password, to replace a forgotten one.
There is some debate as to whether password synchronization makes systems more secure or less. The arguments are as follows:
* Synchronization reduces security:
If a single system is very insecure, then compromising that system will give an intruder the passwords for every other system which uses synchronized passwords.
This weakness is avoided by requiring that users employ unsynchronized passwords on such weak systems.
* Synchronization improves security:
Users with many passwords have trouble remembering them and consequently tend to write them down. System security is reduced to the security of a piece of paper -- i.e., close to zero.
In practice, it is very difficult to get users who have many passwords to stop writing them down. The two arguments above therefore can be restated as:
* Synchronized passwords: as secure as the least secure system in scope.
* Unsynchronized passwords: as secure as slips of paper.
Since most systems and applications make at least some effort to protect their passwords, synchronized passwords are normally more secure. To mitigate the risk of a single system compromise being leveraged by an intruder into a network-wide attack, there are some password management guidelines to follow:
* Very insecure systems, such as those that use little or no cryptography to protect passwords, should not participate in a password synchronization system.
* Synchronized passwords should be changed regularly, on the assumption that either some in-scope systems are vulnerable or that passwords may be compromised through non-digital means (social engineering, etc.).
* Users should be required to select strong (hard to guess) passwords when synchronization is introduced.
The bottom line is that a single, hard-to-guess, regularly changing password is normally more secure than multiple passwords, some of which may be easy to guess, some of which may not be changed regularly and all of which may be written down.
Single sign-on
(11)
Single sign-on (SSO) is any technology that replaces multiple, independent system or application login prompts with a consolidated authentication process, so that users don't have to repeatedly sign in.
Taxonomy of SSO Systems
There are several types of single sign-on systems:
1. Enterprise SSO -- application login prompts continue to ask users to type their login IDs and passwords, but software on the user's PC automatically automatically identifies and fills in these dialogs.
2. Agent-based web SSO -- agents on each web application check whether the incoming web browser (and by extension, its user) has already been authenticated. If so, no further authentication is required.
3. Proxy-based web SSO -- web browsers access web applications through a proxy, which looks up user credentials and injects them into the data stream sent to each web application.
4. Kerberos -- authentication is performed using a separate infrastructure, outside of other systems and applications. Users sign into the Kerberos infrastructure and their computer receives a token, which can be offered to Kerberos-enabled applications instead of filling in a login prompt.
5. Federation -- similar to Kerberos, but designed to allow single sign-on between different organizations (administrative domains). Users sign into a system in one domain and when they try to access an application in another domain, a security assertion is forwarded from their source domain indicating who they are.
Security of SSO Systems
When organizations consider various approaches to single (or reduced) sign-on, they generally need to know:
* Is it secure?
The short answer, in general, is "yes."
The longer answer is more nuanced:
o Strength of the initial authentication:
SSO works by extending the reach of some initial authentication step. So long as that step is robust, subsequent application logins can also be trust worthy. In other words, if users sign into the SSO system with a strong password (as described elsewhere in this document) or using a two-factor technology such as OTP+PIN, Smart card+PIN or biometric+password, then the SSO infrastructure rests on a robust platform. On the other hand, if the SSO system depends on a weak password or PIN, on a proximity card, on a single physical authentication factor (which could be stolen) or on an easily recorded biometric, then the entire system is vulnerable.
o Strength of stored credentials:
Some of the SSO approaches described above depend on assertions, while others depend on the injection of login IDs and passwords into application login prompts. The latter set includes enterprise SSO and proxy-based web SSO.
Injection of application passwords depends on reliable, secure storage of those passwords. This raises the question of where and how these passwords are stored and how a user's SSO agent is authenticated before it is allowed to retrieve these passwords.
For example, if biometrics or proximity badges are used to authenticate users, how can a key be securely generated to decrypt application passwords? If a weak password is the primary means of authentication, what is to stop an attacker from guessing the encryption key that protects other passwords?
* Is it more or less secure than password synchronization?
The answer here is also nuanced, and depends on how users sign into the SSO system in the first place.
o Users sign into SSO with a password:
If password synchronization covers only secure systems, whose password databases have been protected against attack using strong encryption, good password composition rules, regular changes, history, intruder lockout, etc., then the security difference between SSO and synchronization is the difference between compromising a single robust password database (the one used to sign into the SSO system) and compromising any one of several such systems. i.e., infeasible in either case.
o Users sign into SSO with a weak authentication factor:
If users with into the SSO system using a weak password, proximity badge or single physical authentication factor, then the energy that an attacker must expend to compromise all credentials is lower than what the attacker would have to expend to compromise one of several strong password systems.
o Users sign into SSO with a strong authentication factor:
If users with into the SSO system using a two-factor technology or strong password, then the energy that an attacker must expend to compromise all credentials is at least as high as what the attacker would have to expend to compromise one of several strong password systems, with the possible exception of injected passwords (see enterprise SSO and proxy-based web SSO above) with a vulnerable encryption key management scheme.
IT support for forgotten and locked out passwords
(12)
Sometimes users forget their passwords or type the wrong one often enough to trigger an intruder lockout. When this happens, users generally call their IT help desk and ask for the lockout to be cleared or the password to be reset.
The help desk process normally proceeds as follows:
1. User experiences problems trying to log in.
2. User calls the help desk and may wait in a service queue.
3. Support analyst asks the user for his name and a problem description.
4. Support analyst asks the user for information to prove his identity (i.e., authentication of a human by a human).
5. Support analyst compares this information with some on-line resource.
6. If the user is authenticated, the support analyst will generally do one of three things:
1. Reset the forgotten password.
2. Clear the intruder lockout.
3. Forward the support incident to another IT support person, who has the requisite privileges to perform one of the above functions.
7. The user tries to log in with the newly assigned password.
8. The user may be required to change the new password immediately.
Security challenges
The process described above may be vulnerable to security weaknesses:
* The IT support analyst may forget to authenticate the user at all.
* Information suitable for authenticating the caller may not be available to the IT support analyst.
* Information about caller may be easy for an attacker to guess, making the whole process vulnerable to "social engineering" attacks.
* Many IT staff need to be able to reset passwords and clear lockouts for this process to work effectively. This proliferation of privileged accounts (i.e., those of the IT staff) creates an unnecessarily large attack surface.
* Password resets on some systems may not be traceable back to in individual IT support analyst. This creates a lack of accountability and allows IT analysts to compromise user accounts without consequences.
* The support analyst knows the user's new password at the end of the process, so it is no longer truly secret. This is especially problematic when newly reset passwords do not immediately expire.
Mitigating controls
These problems can be overcome through:
* IT support training, to ensure robust authentication of callers prior to every password reset.
* Ensuring that reliable authentication information is available for every user -- including employees, contractors, etc.
* Providing an application proxy that resets passwords on behalf of IT support staff. This way, both IT staff and callers are authenticated before a password can be reset. This reduces the number of privileged accounts and ensures the the process is consistent and secure.
* Allowing users to reset their own forgotten passwords and/or clear their own lockouts, after suitable non-password authentication -- i.e., self-service password reset. This reduces the number of privileged accounts, enforces a robust authentication process and removes the situation where an IT support analyst knows the user's new password.
User authentication
It is important to ensure that users who request a password reset, either by calling the IT support help desk or using self-service, are reliably authenticated. Following are some practical considerations when designing a non-password authentication system:
* One-time-password tokens, smart cards and biometrics are generally more reliable than security questions, because of the vulnerability of security questions to social engineering attacks.
* Where security questions are used (for example, due to their lower cost or easy availability):
o As many questions as possible should be used.
o The difficulty of guessing the answer to each question should be estimated. The total difficulty of guessing enough answers to authenticate as a user should be approximately the same as the difficulty of guessing a user's password.
o Users should provide answers to both personally-chosen and standardized questions. In the former, the questions are harder to guess but answers are sometimes easy to guess. In the latter, the questions are well known to would-be
o A randomly chosen subset of a user's available security questions should be chosen, to make guessing harder for attackers with a limited set of information about a user.
o Intruder lockout should apply to authentication with security questions just as it does to passwords.
Sample security questions are provided in [link].
(13)
Questions with textual answers
Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:
* Which bank branch do you live closest too?
* What car do you wish you owned?
* What is your favorite food?
* Who is your favorite book character?
* What is your favorite game or sport?
* What is your favorite movie?
* What is your favorite pizza topping?
* What is your favorite restaurant?
* What is your favorite season of the year?
* What is your favorite sports team?
* In which department did you first work?
* What was your first position in the company?
* What was your first car?
* Who is the person you admire the most?
* What was the most memorable day in your life?
* Who was your childhood hero?
* What is the nickname of your sibling?
* Who was your first boss?
* What award are you proudest of?
* What city were you born in?
* What is the farthest from home you have traveled?
* What is the name of the first school you attended?
* What is the name of the first person you were romantically interested in?
* What is your astrological sign?
* What is your father's middle name?
* What is your mother's' middle name?
* Who is your favorite actor, actress or celebrity?
* What is your favorite musical band?
* What is your favorite beverage?
* What is your favorite board game?
* Who is your favorite book character?
* What is your favorite dessert?
* What is your favorite hobby or pastime?
* What is your favorite ice cream topping?
* What is your favorite song?
* What is your favorite television show?
* What is your favorite vacation spot?
* What is your mother's maiden name?
* What is your place of birth?
* What is your school team's mascot name?
* What was the breed of your first pet?
* What was the color of your first automobile?
* What were the make and model of your first car?
* What was the name of a favorite childhood pet?
* What was the name of your first girlfriend/boyfriend?
* What was the street name of your childhood home?
* What was your favorite toy when you were a child?
* What did you do on your first job?
* What was your first phone number as a child?
* What year did you purchase your first car?
* What was the name of your first pet?
* Who is your favorite politician?
* Who is your most disliked politician?
* Who is a famous, living person you would most like to meet?
* Who was a famous, now deceased person you would have liked to meet?
* Who is your favorite artist?
* Who is your favorite author?
* With whom did you share your first romantic kiss?
* Who was your favorite elementary school teacher?
Questions with numeric answers
Sample security questions, that have numeric answers and so are suitable for authentication using a touch-tone phone, include:
* What is your favorite radio station (number on the dial - NNNN)?
* In what year did you start with your company?
* On what date were you hired?
* What is your parents' wedding anniversary date?
* Type a significant date in your life (YYYYMMDD)?
* What are the last 4 digits of your SSN?
* What are the last 4 digits of your home phone?
* What is a birth date of a family member?
* What is a relative's telephone number that is not your own?
* What is the date of your anniversary [mm/dd/yyyy]?
* What is the mileage distance you live from your furthest relative?
* What is your Country or employee identification number?
* What is your date of birth (MM/DD/YYYY)?
* What is your driver's license number?
* What is your favorite dial number of radio station?
* What is your favorite or lucky number?
* What is your passport number?
* What is your social security number?
* On what year you will be eligible to retire?
Appendix: References
(14)
This document was prepared by Hitachi ID Systems and reflects expertise with password management accumulated through many deployments of Hitachi ID Password Manager (formerly P-Synch).
* About Hitachi ID Systems:
o http://Hitachi-ID.com
* About Password Manager:
o http://Password-Manager.Hitachi-ID.com
* Password guessing programs:
o http://sectools.org/crackers.html
o http://www.l0phtcrack.com/
o http://www.openwall.com/john/
o ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/
* NIST / FIPS documents about password management:
o http://www.itl.nist.gov/fipspubs/fip112.htm
o http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf
* Best practices for managing passwords for privileged users (as opposed to normal users):
o http://privileged-password-manager.hitachi-id.com/docs/privileged-password-management-best-practices.html
* Unicode and code pages (for multi-lingual users):
o http://unicode.org/
o http://msdn.microsoft.com/en-us/goglobal/bb964654.aspx
o http://msdn.microsoft.com/en-us/goglobal/bb964656.aspx
* Password cracking and password security:
o http://en.wikipedia.org/wiki/Password_cracking
o http://www.cs.unibo.it/%PERCENT montreso/doc/papers/Morris-PasswordSecurity.pdf
* Choosing secure passwords:
o http://www.schneier.com/blog/archives/2007/01/choosing_secure.html
* Disabling LAN Manager passwords on AD:
o http://support.microsoft.com/kb/299656
* Cryptographic hash functions:
o http://en.wikipedia.org/wiki/Cryptographic
* IPSec:
o http://en.wikipedia.org/wiki/IPsec
o http://www.securityfocus.com/infocus/1519
o http://www.ipsec-howto.org/
The guidance in this document is focused on how to best manage user passwords. It is not intended to address the special challenges and techniques that arise when managing privileged passwords, that belong to administrators, service accounts, etc.
Look for the figure marks throughout this document to find best practices.
User authentication and passwords
(1)
Definitions
* Identification
The unique identifier that a user types to sign into a system or application is that user's login ID on that system.
* Authentication
Authentication is a process by which a user proves his identity to a system -- normally when logging in.
* Authentication factor
An authentication factor is something a user presents to a system in order to prove his identity. It may be something he (and hopefully only he) knows, or proof of possession of a physical object, or a measurement of some physical characteristic (biometric) of the living human user. In other words, something the user knows, or something he has, or something he is.
* Multi-factor authentication
Multi-factor authentication means authentication using multiple factors . For example, a user might sign into a system with a combination of two things he knows, or a combination of something he knows and something he has, or perhaps something he knows, something he has and something he is.
The premise is that adding authentication factors makes it more difficult for a would-be attacker to simulate a legitimate authentication and consequently impersonate a legitimate user.
* Strong authentication
Strong authentication refers to an authentication process which is difficult to simulate. It may be based on use of multiple authentication factors or use of a single but hard-to-spoof authentication factor .
Authentication technologies
Authentication technologies may be categorized as follows:
Authentication Factor
Description
Example
Secrets: Something you know.
Secret information known only the user.
A password or PIN.
Tokens: Something you have.
A physical device possessed only be the user.
A one time password (OTP) token or smart card.
Biometrics: Something you are.
A unique, measurable characteristic of the user.
Voice print verification, fingerprint, vein pattern, retina or iris scan.
Generally, it is more secure but less convenient to use multiple forms of authentication -- e.g., a one time password token combined with a password or PIN.
These types of authentication may be further characterized as follows:
Characteristic
Secrets
Tokens
Biometrics
Reliable identification? Good Very good Excellent
Requires client-side hardware No Sometimes Yes
Requires client-side software No Sometimes Yes
Typical deployment cost/user 0 $50 $100
Works with legacy systems Yes No No
Due to cost and compatibility with legacy systems, the most popular form of user authentication continues to be a secret password.
Moreover, as non-password authentication technologies are deployed, they are usually combined with passwords to improve their security. For example, tokens are secure -- unless they are stolen, in which case the person who stole the token can impersonate the legitimate user. This is easily remedied by requiring the user to sign into systems with the OTP displayed on a token plus a password or PIN, which a thief would not know.
The remainder of this document discusses how to best manage passwords, to maximize security and minimize cost of ownership. The guidelines here apply primarily to passwords used as a single authentication factor, but can also be applied to passwords used as a second authentication factor, in conjunction with biometrics, tokens or smart cards.
Security threats
(2)
Passwords are simply secret words or phrases. They can be compromised in many ways:
* Users may write them down or share them, so that they are no longer really secret.
* Passwords can be guessed, either by a person or a program designed to try many possibilities in rapid succession.
* Passwords may be transmitted over a network either in plaintext or encoded in a way which can be readily converted back to plaintext.
* Passwords may be stored on a workstation, server or backup media in plaintext or encoded in a way which can be readily converted back to plaintext.
Each of these vulnerabilities make it easier for someone to acquire the password value and consequently pose as the user whose identity the password protects.
Conversely, if passwords are managed securely by users and if password systems are constructed so as to prevent brute-force attacks and inspection or decryption of passwords in transit and in storage, then passwords can actually be quite secure. This document will describe some of the mechanisms for securing passwords.
Human factors
(3)
Users in a large organization frequently have many passwords, each protecting their account on a different system or application. Users are people, not machines, so their ability to securely manage passwords is intrinsically limited. In particular, it is hard for most people to remember:
* Complicated passwords.
* Many different passwords.
* Passwords that change frequently.
* Passwords for systems that are used infrequently.
Without these constraints, password security would not be a problem and there would be no market for other authentication technologies. For example, if every password was changed every day, was remembered perfectly without being written down and consisted of 100 randomly chosen letters and digits, there would really be no need for authentication technologies other than passwords.
Effective password management is therefore taken to mean password management that is secure, user friendly and supportable within the confines of both technology and human behavior.
When people have trouble remembering their passwords, they usually resort to one or more of the following:
* Write down their passwords -- and reduce the security of systems to the security of their physical building, desk or wallet.
* Forget their passwords -- and require frequent assistance from an IT help desk to reset it.
* Use very simple, easily compromised passwords.
* Reuse old passwords as often as possible.
Clearly, sound password management practices must take into consideration human limitations, to reduce the frequency of these insecure practices.
Composing hard-to-guess passwords
(4)
As outlined in (2), one of the weaknesses of passwords is that they can be guessed. While a human may give up after ten or a hundred guesses, software s available to automate the guessing process and try millions of possible passwords per second:
* L0phtCrack: http://www.l0phtcrack.com/ for Windows.
* John the Ripper: http://www.openwall.com/john/ for Windows, Mac OS X or Linux.
* Many others.
To combat password guessing attack, users should pick hard-to-guess passwords. One way to do this is to ensure that the set of all possible passwords is too large to search thoroughly and then to eliminate probable guesses, which an attacker might try first.
The number of possible password combinations is calculated by taking the number of legal characters in a password and raising that number to the number of characters in the password. The possibilities for some typical combinations are shown below:
Character set
5
6
7
8
9
10
0-9 1.00e05 1.00e06 1.00e07 1.00e08 1.00e09 1.00e10
a-z 1.19e07 3.09e08 8.03e09 2.09e11 5.43e12 1.41e14
a-z,0-9 6.05e07 2.18e09 7.84e10 2.82e12 1.02e14 3.66e15
a-z,0-9,3 punct 9.02e07 3.52e09 1.37e11 5.35e12 2.09e14 8.14e15
a-z,A-Z 3.80e08 1.98e10 1.03e12 5.35e13 2.78e15 1.45e17
a-z,A-Z,0-9 9.16e08 5.68e10 3.52e12 2.18e14 1.35e16 8.39e17
a-z,A-Z,0-9,32 punct 7.34e09 6.90e11 6.48e13 6.10e15 5.73e17 5.39e19
Users should choose their passwords from the widest possible set of characters, subject to the constraints of the systems where those passwords reside. For example, most mainframes do not distinguish between uppercase and lowercase and only allow three punctuation marks (fourth row in the table above).
The policy should be based on the smallest acceptable set of possible password values. This, in turn, depends on how fast an attacker can check if a possible password is valid; how much time an attacker has to attack a given password and how log we want the attacker's probability of success to be.
This is best illustrated with an example:
1. Assumptions:
1. Encrypted passwords are not available to an attacker and consequently passwords can only be guessed at a rate of 100/second (this number is high / conservative for an over-the-network attack).
2. An attacker can make an unlimited number of guesses without being detected (this is easy to fix).
3. Passwords are changed, at most, every 90 days.
2. Objective: the attacker's probability of success should be no more than 1%.
3. Technical constraints: passwords may only contain lowercase letters, uppercase letters and digits.
4. Calculation:
1. An attacker can make 90 x 24 x 60 x 60 x 100 = 777,600,000 guesses before a password will expire.
2. There should be 77,760,000,000 possible passwords -- about 8e10.
3. From the above table, a 7 character password is sufficient, so long as users don't pick easily guessed values (e.g., their name or a dictionary word).
In practice, assuming that encrypted passwords are not available to an attacker and that passwords cannot be captured or decrypted in transit, the following policy is a often reasonable:
* To ensure that the search space is sufficiently large:
o Passwords must be at least seven characters long.
o Passwords must contain at least one lowercase letter, at least one uppercase letter and at least one digit.
o If technically possible, passwords must contain at least one punctuation mark, so long as there are many (10 or more) available punctuation marks.
* To eliminate trivial passwords, passwords should not:
o Contain the user's name or login ID.
o Contain a dictionary word, in any language that users can reasonably be expected to know.
o More than two paired letters (e.g. abbcdde is valid, but abbbcdd is not).
Some of these rules merit further discussion, since a naive implementation of the rule can actually reduce password security. Consider the rule "password should not contain a dictionary word." The letters "a" and "I" are legitimate English words, and if the rule is enforced using a dictionary that contains these, then in effect we have reduced the set of available letters from 26 to 24. To avoid this sort of problem, rules of the form "shall not contain" should be fine-tuned:
* Ignore words with 3 or fewer characters, since including such words in a dictionary check may actually make passwords easier to guess, by eliminating too many legitimate password values.
* Consider dictionary words without regard to case. "Hello12" should not be a valid password, even if the dictionary contains "hello" but not "Hello".
Unicode and other non-Latin passwords
(5)
Most password composition rules focus on how passwords composed of Latin characters (i.e., "English language" letters), digits and punctuation marks are composed.
Unfortunately, English is the native language of no more than 400 million people and is spoken by no more than 1.5 billion people -- out of a global population of over 6.5 billion people. In other words, even if other European languages that use a similar character set are included, a focus on Latin characters ignores at least 2/3 of the world's population.
This not just an academic problem. Many organizations are global in nature and include users who speak a variety of languages. A system or application whose users reside around the world needs to enforce a password policy that makes sense for all of them, not just for those who happen to prefer English.
Password management for multi-lingual users is a broad subject, but following are some important considerations:
1. Most users, in most countries, have keyboards that include most Latin characters. This means that they are able to type passwords composed of "English" letters, even if they don't read or write the language.
2. Not every system or application supports non-Latin characters in the password field. When composing an enterprise password policy, it's important to consider the limitations on the password fields of in-scope systems and applications. Failing to do this can yield a policy that is relevant to only some systems.
3. In countries where Chinese, Japanese or Korean (CJK) is spoken, text input often involves a display component. For example, a Chinese user might type the pinyin representation of a character and the input software will display a list of matching characters. The user will then choose the desired character and start on the next character.
This pattern is normal for input of text in the CJK languages but is problematic for passwords since password input should not be visible to other people in the physical vicinity.
Most CJK users avoid this problem by choosing passwords that consist only of Latin characters -- something that may surprise native English speakers.
Some best practices follow from this discussion:
1. Encourage or require users to restrict their passwords to Latin characters, both for compatibility and to avoid input methods which display the characters users type.
2. Do use a dictionary lookup to ensure that new passwords are hard to guess, and do include dictionaries of non-English words represented in Latin character sets (e.g., Pinyin, etc.).
Changing and reusing passwords
(6)
Over time, passwords may be compromised in many ways, including:
* Users may share them with friends or coworkers.
* Users may write them down and they may subsequently be exposed.
* Passwords may be guessed, either by humans or software.
* The servers that store passwords may be compromised and their passwords acquired by an intruder (encrypted, hashed or plaintext).
* The networks over which passwords travel, between a user's workstation and the system into which the user signs in may be compromised, again leading to compromise of a password.
* Users may be tricked into revealing their passwords (phishing).
* The help desk may be tricked into giving an intruder a valid password (social engineering).
To limit the usefulness of passwords that have been compromised, a best practice is to change them regularly. A common rule in many organizations is to force users to change their passwords when they log in, every 60 or 90 days.
In general, users should be required to change their passwords regularly. The password expiry interval should not be longer than 90 days.
For the same reasons, users should not reuse old passwords, as they may already have been compromised. Many systems support this by recording some representation of old passwords and ensuring that users cannot change their password back to a previously used value.
When password history is enforced, users may figure out the number of passwords stored for this purpose. As this number is usually 10 or fewer, a user who would prefer to keep his password the same may make a series of consecutive password changes where the final password value is the same as the first one.
To defeat such "smart" users, some systems also enforce a password rule that limits the number of password changes that a user can make in any given day. By making the process of defeating password history take several days, users are discouraged from trying to reuse old passwords.
A better approach, though not available on all systems, is to simply maintain an unlimited number of entries in each user's password history. Since disk storage is inexpensive, this approach is practical on modern systems. With this approach, users can change their passwords as often as they like -- and still never be able to reuse old ones.
Keeping passwords secret
(7)
Passwords are intended to reliably differentiate between the authentic user and impostors. As such, they must be secrets -- known only to the user they identify.
Users frequently behave in ways that lead to password disclosure. In particular, users may:
* Choose passwords which are easily guessed -- so are not really secret.
* Share their passwords with coworkers, friends or family.
* Write down their passwords and place the written password near their computer or in a supposedly private place like a wallet.
A comprehensive password policy should explicitly forbid these behaviors and specify negative consequences to users who violate the policy.
To help users comply with an effective password policy, user friendly password management tools and processes should be provided. Key among such aids to users are password synchronization and single sign-on.
With either synchronized or automatically filled-in passwords, users have fewer passwords to remember so they are less likely to write down their passwords.
Intruder detection and lockout
(8)
Many systems can detect repeated attempts to sign into an account with incorrect passwords. A pattern of failed logins may be due to:
1. Typing problems. For example, the user may have the Caps Lock or Num Lock key enabled and not realize it.
2. A forgotten password.
3. The wrong password being used. For example, the user may be trying to sign into system A using the password for system B.
4. An intruder trying to sign into an account by guessing the legitimate user's password.
To deter the last of these, it's reasonable for a system that detects too many invalid attempts during a short period of time to lock out the user's account and prevent further attempts, at least for a while. This is called an intruder lockout.
Many systems include an "intruder lockout" feature. If N invalid attempts to login to the same account are made during an interval of Tdetect minutes, then the account is disabled for Tlockout minutes.
While this mechanism is effective against concerted attacks against a single account, it does nothing to prevent an intruder from simultaneously trying to guess the passwords of many users. A more sophisticated mechanism might extend this as follows: If M invalid login attempts are made from network address A, to any account, during an interval of Tdetect minutes, then the address A is disabled for Tlockout minutes.
This will deter intruders with access to just a single network device/address from which to carry out their attack.
Intruder lockout also has a down side -- it can be used to carry out a denial of service -- by systematically locking out many accounts, including administrator IDs.
Because of these fundamental limitations, the best practice is to combine several intruder lockout-related policies:
* Apply only to users, exempting at least one administrator login. This limits the scope of denial of service attacks.
* A compensating control is required here, such as requiring administrator IDs to have very complex passwords that are changed more frequently than user passwords. This way, they cannot be guessed (too hard) or locked out (feature not available).
* Apply a high threshold for intruder detection -- for example, 10 failed login attempts in 5 minutes. This prevents spurious lockouts caused by users who have trouble remembering or typing their own passwords.
* Automatically and quickly clear lockouts -- for example, after 10 or 15 minutes. This reduces the impact on legitimate users while continuing to significantly impair the ability of intruders to make bulk password guessing attacks.
Encrypting passwords in storage and transit
(9)
Passwords may be stored on user workstations or servers. They must be transmitted, in some form, from the user's workstation to a server when the user signs into systems and applications.
Most organizations are powerless to improve the manner in which existing infrastructure uses encryption to protect passwords. However, staff responsible for developing a new applications that include password authentication can and should take effective precautions, such as storing passwords using a well-known and trusted hashing algorithm such as SHA-256 or (somewhat less effective, but still infeasible to find a collision in 2010) SHA-1.
Passwords transmitted from a client device to a server are similarly subject to weaknesses in the protocol used by the relevant application. For example, Telnet and TN3270 are plaintext while SSH and SSL are strongly encrypted. Where password security is important and where one cannot trust the physical security of all communication media between a user and the systems he logs into, then additional mechanisms, such as IPSec should be considered to protect that communication.
Some client devices and applications cache passwords and automatically provide them to servers on behalf of users, as required. Cached passwords should also be cryptographically protected, but in this case encryption rather than hashing is required, since the password must be recoverable.
In some cases, the protocol provided by a vendor may encrypt passwords when they are used to login to a system, but not when a password change is transmitted. This happens with Oracle SQL*Net, for example. In these cases, if password management software is deployed, it is helpful for that software to implement its own encryption for password transmission, beyond that provided natively by the application vendor.
Synchronizing passwords
(10)
Password synchronization technology helps users to maintain the same password on two or more systems. This, in turn, makes it easier for users to remember their passwords, reducing the need to write down passwords or to call an IT help desk to request a new password, to replace a forgotten one.
There is some debate as to whether password synchronization makes systems more secure or less. The arguments are as follows:
* Synchronization reduces security:
If a single system is very insecure, then compromising that system will give an intruder the passwords for every other system which uses synchronized passwords.
This weakness is avoided by requiring that users employ unsynchronized passwords on such weak systems.
* Synchronization improves security:
Users with many passwords have trouble remembering them and consequently tend to write them down. System security is reduced to the security of a piece of paper -- i.e., close to zero.
In practice, it is very difficult to get users who have many passwords to stop writing them down. The two arguments above therefore can be restated as:
* Synchronized passwords: as secure as the least secure system in scope.
* Unsynchronized passwords: as secure as slips of paper.
Since most systems and applications make at least some effort to protect their passwords, synchronized passwords are normally more secure. To mitigate the risk of a single system compromise being leveraged by an intruder into a network-wide attack, there are some password management guidelines to follow:
* Very insecure systems, such as those that use little or no cryptography to protect passwords, should not participate in a password synchronization system.
* Synchronized passwords should be changed regularly, on the assumption that either some in-scope systems are vulnerable or that passwords may be compromised through non-digital means (social engineering, etc.).
* Users should be required to select strong (hard to guess) passwords when synchronization is introduced.
The bottom line is that a single, hard-to-guess, regularly changing password is normally more secure than multiple passwords, some of which may be easy to guess, some of which may not be changed regularly and all of which may be written down.
Single sign-on
(11)
Single sign-on (SSO) is any technology that replaces multiple, independent system or application login prompts with a consolidated authentication process, so that users don't have to repeatedly sign in.
Taxonomy of SSO Systems
There are several types of single sign-on systems:
1. Enterprise SSO -- application login prompts continue to ask users to type their login IDs and passwords, but software on the user's PC automatically automatically identifies and fills in these dialogs.
2. Agent-based web SSO -- agents on each web application check whether the incoming web browser (and by extension, its user) has already been authenticated. If so, no further authentication is required.
3. Proxy-based web SSO -- web browsers access web applications through a proxy, which looks up user credentials and injects them into the data stream sent to each web application.
4. Kerberos -- authentication is performed using a separate infrastructure, outside of other systems and applications. Users sign into the Kerberos infrastructure and their computer receives a token, which can be offered to Kerberos-enabled applications instead of filling in a login prompt.
5. Federation -- similar to Kerberos, but designed to allow single sign-on between different organizations (administrative domains). Users sign into a system in one domain and when they try to access an application in another domain, a security assertion is forwarded from their source domain indicating who they are.
Security of SSO Systems
When organizations consider various approaches to single (or reduced) sign-on, they generally need to know:
* Is it secure?
The short answer, in general, is "yes."
The longer answer is more nuanced:
o Strength of the initial authentication:
SSO works by extending the reach of some initial authentication step. So long as that step is robust, subsequent application logins can also be trust worthy. In other words, if users sign into the SSO system with a strong password (as described elsewhere in this document) or using a two-factor technology such as OTP+PIN, Smart card+PIN or biometric+password, then the SSO infrastructure rests on a robust platform. On the other hand, if the SSO system depends on a weak password or PIN, on a proximity card, on a single physical authentication factor (which could be stolen) or on an easily recorded biometric, then the entire system is vulnerable.
o Strength of stored credentials:
Some of the SSO approaches described above depend on assertions, while others depend on the injection of login IDs and passwords into application login prompts. The latter set includes enterprise SSO and proxy-based web SSO.
Injection of application passwords depends on reliable, secure storage of those passwords. This raises the question of where and how these passwords are stored and how a user's SSO agent is authenticated before it is allowed to retrieve these passwords.
For example, if biometrics or proximity badges are used to authenticate users, how can a key be securely generated to decrypt application passwords? If a weak password is the primary means of authentication, what is to stop an attacker from guessing the encryption key that protects other passwords?
* Is it more or less secure than password synchronization?
The answer here is also nuanced, and depends on how users sign into the SSO system in the first place.
o Users sign into SSO with a password:
If password synchronization covers only secure systems, whose password databases have been protected against attack using strong encryption, good password composition rules, regular changes, history, intruder lockout, etc., then the security difference between SSO and synchronization is the difference between compromising a single robust password database (the one used to sign into the SSO system) and compromising any one of several such systems. i.e., infeasible in either case.
o Users sign into SSO with a weak authentication factor:
If users with into the SSO system using a weak password, proximity badge or single physical authentication factor, then the energy that an attacker must expend to compromise all credentials is lower than what the attacker would have to expend to compromise one of several strong password systems.
o Users sign into SSO with a strong authentication factor:
If users with into the SSO system using a two-factor technology or strong password, then the energy that an attacker must expend to compromise all credentials is at least as high as what the attacker would have to expend to compromise one of several strong password systems, with the possible exception of injected passwords (see enterprise SSO and proxy-based web SSO above) with a vulnerable encryption key management scheme.
IT support for forgotten and locked out passwords
(12)
Sometimes users forget their passwords or type the wrong one often enough to trigger an intruder lockout. When this happens, users generally call their IT help desk and ask for the lockout to be cleared or the password to be reset.
The help desk process normally proceeds as follows:
1. User experiences problems trying to log in.
2. User calls the help desk and may wait in a service queue.
3. Support analyst asks the user for his name and a problem description.
4. Support analyst asks the user for information to prove his identity (i.e., authentication of a human by a human).
5. Support analyst compares this information with some on-line resource.
6. If the user is authenticated, the support analyst will generally do one of three things:
1. Reset the forgotten password.
2. Clear the intruder lockout.
3. Forward the support incident to another IT support person, who has the requisite privileges to perform one of the above functions.
7. The user tries to log in with the newly assigned password.
8. The user may be required to change the new password immediately.
Security challenges
The process described above may be vulnerable to security weaknesses:
* The IT support analyst may forget to authenticate the user at all.
* Information suitable for authenticating the caller may not be available to the IT support analyst.
* Information about caller may be easy for an attacker to guess, making the whole process vulnerable to "social engineering" attacks.
* Many IT staff need to be able to reset passwords and clear lockouts for this process to work effectively. This proliferation of privileged accounts (i.e., those of the IT staff) creates an unnecessarily large attack surface.
* Password resets on some systems may not be traceable back to in individual IT support analyst. This creates a lack of accountability and allows IT analysts to compromise user accounts without consequences.
* The support analyst knows the user's new password at the end of the process, so it is no longer truly secret. This is especially problematic when newly reset passwords do not immediately expire.
Mitigating controls
These problems can be overcome through:
* IT support training, to ensure robust authentication of callers prior to every password reset.
* Ensuring that reliable authentication information is available for every user -- including employees, contractors, etc.
* Providing an application proxy that resets passwords on behalf of IT support staff. This way, both IT staff and callers are authenticated before a password can be reset. This reduces the number of privileged accounts and ensures the the process is consistent and secure.
* Allowing users to reset their own forgotten passwords and/or clear their own lockouts, after suitable non-password authentication -- i.e., self-service password reset. This reduces the number of privileged accounts, enforces a robust authentication process and removes the situation where an IT support analyst knows the user's new password.
User authentication
It is important to ensure that users who request a password reset, either by calling the IT support help desk or using self-service, are reliably authenticated. Following are some practical considerations when designing a non-password authentication system:
* One-time-password tokens, smart cards and biometrics are generally more reliable than security questions, because of the vulnerability of security questions to social engineering attacks.
* Where security questions are used (for example, due to their lower cost or easy availability):
o As many questions as possible should be used.
o The difficulty of guessing the answer to each question should be estimated. The total difficulty of guessing enough answers to authenticate as a user should be approximately the same as the difficulty of guessing a user's password.
o Users should provide answers to both personally-chosen and standardized questions. In the former, the questions are harder to guess but answers are sometimes easy to guess. In the latter, the questions are well known to would-be
o A randomly chosen subset of a user's available security questions should be chosen, to make guessing harder for attackers with a limited set of information about a user.
o Intruder lockout should apply to authentication with security questions just as it does to passwords.
Sample security questions are provided in [link].
(13)
Questions with textual answers
Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:
* Which bank branch do you live closest too?
* What car do you wish you owned?
* What is your favorite food?
* Who is your favorite book character?
* What is your favorite game or sport?
* What is your favorite movie?
* What is your favorite pizza topping?
* What is your favorite restaurant?
* What is your favorite season of the year?
* What is your favorite sports team?
* In which department did you first work?
* What was your first position in the company?
* What was your first car?
* Who is the person you admire the most?
* What was the most memorable day in your life?
* Who was your childhood hero?
* What is the nickname of your sibling?
* Who was your first boss?
* What award are you proudest of?
* What city were you born in?
* What is the farthest from home you have traveled?
* What is the name of the first school you attended?
* What is the name of the first person you were romantically interested in?
* What is your astrological sign?
* What is your father's middle name?
* What is your mother's' middle name?
* Who is your favorite actor, actress or celebrity?
* What is your favorite musical band?
* What is your favorite beverage?
* What is your favorite board game?
* Who is your favorite book character?
* What is your favorite dessert?
* What is your favorite hobby or pastime?
* What is your favorite ice cream topping?
* What is your favorite song?
* What is your favorite television show?
* What is your favorite vacation spot?
* What is your mother's maiden name?
* What is your place of birth?
* What is your school team's mascot name?
* What was the breed of your first pet?
* What was the color of your first automobile?
* What were the make and model of your first car?
* What was the name of a favorite childhood pet?
* What was the name of your first girlfriend/boyfriend?
* What was the street name of your childhood home?
* What was your favorite toy when you were a child?
* What did you do on your first job?
* What was your first phone number as a child?
* What year did you purchase your first car?
* What was the name of your first pet?
* Who is your favorite politician?
* Who is your most disliked politician?
* Who is a famous, living person you would most like to meet?
* Who was a famous, now deceased person you would have liked to meet?
* Who is your favorite artist?
* Who is your favorite author?
* With whom did you share your first romantic kiss?
* Who was your favorite elementary school teacher?
Questions with numeric answers
Sample security questions, that have numeric answers and so are suitable for authentication using a touch-tone phone, include:
* What is your favorite radio station (number on the dial - NNNN)?
* In what year did you start with your company?
* On what date were you hired?
* What is your parents' wedding anniversary date?
* Type a significant date in your life (YYYYMMDD)?
* What are the last 4 digits of your SSN?
* What are the last 4 digits of your home phone?
* What is a birth date of a family member?
* What is a relative's telephone number that is not your own?
* What is the date of your anniversary [mm/dd/yyyy]?
* What is the mileage distance you live from your furthest relative?
* What is your Country or employee identification number?
* What is your date of birth (MM/DD/YYYY)?
* What is your driver's license number?
* What is your favorite dial number of radio station?
* What is your favorite or lucky number?
* What is your passport number?
* What is your social security number?
* On what year you will be eligible to retire?
Appendix: References
(14)
This document was prepared by Hitachi ID Systems and reflects expertise with password management accumulated through many deployments of Hitachi ID Password Manager (formerly P-Synch).
* About Hitachi ID Systems:
o http://Hitachi-ID.com
* About Password Manager:
o http://Password-Manager.Hitachi-ID.com
* Password guessing programs:
o http://sectools.org/crackers.html
o http://www.l0phtcrack.com/
o http://www.openwall.com/john/
o ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/
* NIST / FIPS documents about password management:
o http://www.itl.nist.gov/fipspubs/fip112.htm
o http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf
* Best practices for managing passwords for privileged users (as opposed to normal users):
o http://privileged-password-manager.hitachi-id.com/docs/privileged-password-management-best-practices.html
* Unicode and code pages (for multi-lingual users):
o http://unicode.org/
o http://msdn.microsoft.com/en-us/goglobal/bb964654.aspx
o http://msdn.microsoft.com/en-us/goglobal/bb964656.aspx
* Password cracking and password security:
o http://en.wikipedia.org/wiki/Password_cracking
o http://www.cs.unibo.it/%PERCENT montreso/doc/papers/Morris-PasswordSecurity.pdf
* Choosing secure passwords:
o http://www.schneier.com/blog/archives/2007/01/choosing_secure.html
* Disabling LAN Manager passwords on AD:
o http://support.microsoft.com/kb/299656
* Cryptographic hash functions:
o http://en.wikipedia.org/wiki/Cryptographic
* IPSec:
o http://en.wikipedia.org/wiki/IPsec
o http://www.securityfocus.com/infocus/1519
o http://www.ipsec-howto.org/
Friday, October 08, 2010
Kisah Genius Islam Ibnu Sina
Rencah Oleh: blalang
"Ibnu SinaSemoga biografi ringkas Ibnu Sina ini boleh meningkatkan motivasi kita-kita semua dalam menuntut ilmu dan mengamalkannya dalam kehidupan kita
Nama penuh beliau ialah Abu Ali al Husain ibn Abdullah ibn Sina dan lebih dikenali di masyarakat Eropah dengan sebutan “Avicenna”. Nama panggilan lain beliau selain Ibnu Sina adalah Abu Ali. Beliau adalah salah seorang genius yang mahir dalam pelbagai cabang ilmu.
Beliaulah orang yang membuat ensiklopedia terkemuka dan pakar dalam bidang agama, perubatan, falsafah, logik, matematik, astronomi dan muzik. Selain itu beliau juga seorang pustakawan dan pakar psikiatri yang handal.
Ibnu sina dilahirkan di Afsyinah, sebuah kampung yang terletak berhampiran Bukhara (Republik Uzbekistan) tahun 370 H / 980 M. Ayah Ibnu Sina adalah seorang gabenor Samanite yang ditugaskan di Bukhara. Beliau berasal dari Balakh kemudian berpindah ke Bukhara pada zaman pemerintahan Al-Amir Nuh bin Mansur dan tinggal di perkampungan kecil di Bukhara yang bernama Khirmitan. Namun akhirnya beliau menetap di Afsyanah kerana berhampiran dengan tempat kerjanya. Sejak kecil beliau telah memperlihatkan kepintarannya yang cemerlang dan kemajuan yang luar biasa dalam menerima pendidikan. Ibnu Sina kecil yang tangkas mula belajar al-Quran pada usia 5 tahun. Sejak usia lima tahun itu Ibnu Sina telah mendapatkan pendidikan al-Quran dan sastera dari ayahnya. Pada usia sepuluh tahun ia sudah hafal al-Quran, menguasai ilmu sastera, tasawuf, dan geometri. Belum genap usia 16 tahun, Ibnu Sina sudah menguasai ilmu perubatan. Semasa itulah dia bermula merawat pesakit. Segala kerja kerasnya selama ini berhasil. Ketekunannya dalam mempelajari pelbagai disiplin ilmu menjadikannya pakar dalam berbagai ilmu.
Kemudian nama Ibnu Sina mula dikenali ramai orang. Bahkan di negeri jiran pun, beliau menjadi bahan perbualan.Ramai orang dari negeri jiran datang berjumpa beliau untuk berbincang. Berduyun-duyun penduduk dari berbagai negeri datang untuk berguru dan berubat pada beliau. Ibnu Sina tak pernah berhenti belajar demi mengembangkan keilmuannya. Walaupun selalunya dia tertidur kelelahan. Di usia 17 tahun, di tengah usahanya untuk menyembuhkan penyakit baginda Nabi Nuh bin Mansur, ia terus mengembangkan ilmunya. Sebagai penghargaan raja atas jasanya yang berjaya menyembuhkan raja. Baginda meminta Ibnu Sina menetap di istana, sekurang-kurangnya untuk sementara semasa raja dalam proses penyembuhan. Tapi Ibnu Sina menolaknya dengan halus, sebagai gantinya ia hanya meminta izin untuk mengunjungi sebuah perpustakaan kerajaan yang kuno dan antik. Siapa sangka, dari sanalah ilmunya yang luas ditambah lagi semangat belajarnya yang tinggi. Ia tidak pernah melewatkan waktu sedikitpun untuk bermalas-malasan. Beberapa karyapun telah dilahirkan. Selama 1,5 tahun Ibnu Sina jarang tidur, penuh dengan berbagai ilmu dan analisa. Semangat belajarnya kuat sekali. Ibnu Sina selalu memikirkan ilmu yang sedang dipelajarinya sampai ia memahaminya. Ibnu Sina tidak hanya belajar teori tetapi juga mempraktikkannya. Pengalaman ilmunya terhadap apa yang dipelajari semakin luar biasa.
Ibnu Sina tak pernah berhenti belajar. Ilmunya semakin matang dan mendalam. Pada usia 21 tahun, Ibnu Sina berjaya membuat buku pertamanya, Al-Majmu ‘ketika berada di Khawarazm yang mengandungi berbagai ilmu pengetahuan yang lengkap. Beliau menyelesaikannya berdasarkan semua disiplin ilmu yang dipelajarinya. Ketika terjadi kekacauan di Kerajaan As-Samani, Ibnu Sina mula melakukan pengembaraan. Beliau keluar dari Bukhara menuju Karkang. Dari situ beliau berpindah ke Jarjan dan Khurasan. Namun demikian, pada akhirnya Ibnu Sina meninggalkan kedua-dua negara tersebut menuju ke Dahastan. Setelah itu, Ibnu Sina kembali ke Jarjan dan bertemu dengan Juzjani. Di Jarjan, Ibnu Sina menjadi menteri sebanyak dua kali. Meski demikian, beliau tidak pernah berhenti menulis, mengajar, dan mengarang. Malam hari, beliau mengajar dan pagi hari beliau bertolak ke pejabat Kementerian tempat beliau tugaskan. Buku yang ditulis Ibnu Sina lebih kurang 250 judul, termasuk kitab, esei, dan artikel dalam bidang matematik, mantik, akhlak, fizik, perubatan dan falsafah.
“>Ibnu Sina
Buku-buku yang pernah dikarang oleh Ibnu Sina, dihimpun dalam buku besar Essai de Bibliographie Avicenna yang ditulis oleh Pater Dominician di Kaherah. Karya-karya beliau semasa hidupnya antara lain:
1. Kitab Al Majmu ‘, tentang ilmu pengetahuan yang lengkap ditulis saat beliau berusia 21 tahun.
2. Kitab Asy-Syifa, (The Books of Recovery / The Books of Remedy), tentang cara-cara rawatan beserta ubatnya (18 jilid). Kitab ini di dunia perubatan menjadi ensiklopedia falsafah perubatan. Dalam bahasa latin kitab ini dikenali dengan nama “Sanatio”.
3. Kitab Al Qanun Fit Thibb (Canon of Medicine). tentang cara rawatan yang sistematik (16 jilid). Memuatkan kenyataan yang tegas bahawa darah mengalir terus-menerus dalam suatu lingkaran dan tidak pernah berhenti. Buku ini sejak zaman Dinasti Han di China telah menjadi rujukan standard karya-karya perubatan cina.
Photobucket
Bab Mata dalam buku Qanun at thib.
4. Kitab Remedies for the Heart, mengandungi sajak-sajak. Mengandung sajak-sajak perubatan yang menghuraikan tentang 760 jenis penyakit beserta cara pengubatannya.
5. Kitab An Najah, tentang falsafah.
6. Penemuan tentang anatomi tubuh. Ibnu Sina percaya bahawa setiap tubuh manusia terdiri daripada empat unsur iaitu tanah, air, api dan angin. Keempat unsur itu memberi sifat lembap, sejuk, panas, dan kering serta sentiasa bergantung pada unsur lain yang terdapat pada alam ini.
7. Penemuan tentang rawatan psikomosaik. Beliau mengembangkan ilmu diagnosis melalui denyutan jantung (pulse diagnosis) untuk mengetahui secara pasti keseimbangan emosi seseorang dalam beberapa saat.
8. Penemuan di bidang kimia tentang logam. Beliu menerangkan bahawa benda-benda logam sebenarnya berbeza antara satu dengan yang lain secara khusus. Setiap logam membentuk dengan sendirinya dengan pelbagai jenis. Beliau dianggap penerus dari perkembangan ilmu kimia yang telah dirintis oleh Jabir Ibnu Hayyan (Bapa Kimia Muslim Pertama).
9. Penemuan di bidang geografi tentang asal usul lembah.
10. Penemuan tentang peredaran darah. Beliau mendapati bahawa “Darah mengalir terus menerus dalam suatu lingkaran dan tidak pernah berhenti.”
11. Kitab Fi Aqsamil Ulumil Aqliya (On the Division of the Rational Sciences) tentang pembahagian ilmu-ilmu rasional.Kitab An Nayat (Book of Deliverence) buku tentang kebahagiaan jiwa (merupakan sebuah buku psikologi.
12. Kitab Risalah As Siyasah (Book of Politics) tentang politik.
13. Penemuan di bidang bahan perubatan.
14. Penemuan dalam bidang psikoterapi.
15. Kitab Al Musiqa, tentang muzik.
16. Kitab Al Mantiq, tentang logik. Buku ini dipersembahkan untuk Abu Hasan Sahil.
17. Kitab Uyun Al Hikmah (10 jilid) tentang falsafah. Ensiklopedio Britanica menyebutkan bahawa kemungkinan besar buku ini telah hilang.
18. Kitab Al Hikmah El Masyriqiyyin, tentang falsafah timur.
19. Kitab Al Insyaf tentang keadilan sejati.
20. Kitab Al Isyarat Wat Tanbihat, tentang prinsip ketuhanan dan sembahyang.
21. Kitab Al Isaguji (The Isagoge), tentang logik
22. Kitab Fi Ad Din (Liber de Mineralibus) tentang mineral.
23. Kitab Al Qasidah Al Aniyyah, tentang prosa.
24. Kitab Sadidiya, tentang perubatan.
25. Kitab Risalah At Thayr, tentang karangan roman.
26. Kitab Danesh Nameh, tentang falsafah.
27. Kitb Mujir. Kabir Wa Saghir, tentang dasar-dasar ilmu logik secara lengkap.
28. Salama wa Absal, Hayy ibn Yaqzan, al-Ghurfatul Gharabiyyah (Pengasingan di Barat) dan Risalatul Thayr (Risalah Burung).
Ibnu Sina
Karya Ibnu Sina Berupa Kitab Al Qanun Fit Thibb (Canon of Medicine) telah digunakan sebagai buku teks perubatan di pelbagai universiti di Perancis. Misalnya di Sekolah Tinggi Perubatan Montpellier dan Louvin yang telah menggunakannya sebagai bahan rujukan pada abad ke-17 M. Sementara itu, Prof. Phillip K. Hitti telah menganggap buku tersebut sebagai “Ensiklopedia Perubatan”. Buku ini telah membincangkan serta membahas tentang penyakit saraf. Arahan tersebut juga membahas cara-cara pembedahan yang menekankan tentang keperluan pembersihan luka. Bahkan di dalam buku-buku tersebut juga dinyatakan keterangan dengan lebih jelas disamping gambar-gambar dan sketsa-sketsa yang sekaligus menunjukkan pengetahuan anatomi Ibnu Sina yang luas.
Penulis-penulis barat telah menganggap Ibnu Sina sebagai “Bapa Perubatan” kerana beliau telah menggabungkan teori perubatan Yunani Hipocrates dan Galen dan pengalaman dari ahli-ahli perubatan dari India dan Parsi serta pengalaman beliau sendiri, Ibnu Sina meninggal pada tahun 1073, semasa kembali ke kota yang disukainya Hamadhan. Walau beliau sudah meninggal, namun berbagai ilmunya sangat berguna dan digunakan untuk penyembuhan berbagai penyakit yang kini diderita umat manusia.
Beliau sudah tiada, tapi akan selalu menemani kita. Sekarang, kita harus meneruskan setiap karyanya. Jangan sampai kita hanya boleh bernostalgia dengan membaca sejarah beliau. Ikrarkan dalam hati bahawa “Kita boleh seperti beliau, beliau boleh begitu juga kita”. Jangan kita hanya kagum sahaja tapi kita tidak mahu menggali ilmu yang beliau tinggalkan. Sebab ilmu yang beliau tinggalkan tidak kita pergunakan dan kembangkan dengan baik. Malah, orang barat yang mengembangkannya. Sudah masanya kita bangkit dan kita capai kegemilangan islam dengan ilmu pengetahuan serta iman dan taqwa.
credit to tranungkite
"Ibnu SinaSemoga biografi ringkas Ibnu Sina ini boleh meningkatkan motivasi kita-kita semua dalam menuntut ilmu dan mengamalkannya dalam kehidupan kita
Nama penuh beliau ialah Abu Ali al Husain ibn Abdullah ibn Sina dan lebih dikenali di masyarakat Eropah dengan sebutan “Avicenna”. Nama panggilan lain beliau selain Ibnu Sina adalah Abu Ali. Beliau adalah salah seorang genius yang mahir dalam pelbagai cabang ilmu.
Beliaulah orang yang membuat ensiklopedia terkemuka dan pakar dalam bidang agama, perubatan, falsafah, logik, matematik, astronomi dan muzik. Selain itu beliau juga seorang pustakawan dan pakar psikiatri yang handal.
Ibnu sina dilahirkan di Afsyinah, sebuah kampung yang terletak berhampiran Bukhara (Republik Uzbekistan) tahun 370 H / 980 M. Ayah Ibnu Sina adalah seorang gabenor Samanite yang ditugaskan di Bukhara. Beliau berasal dari Balakh kemudian berpindah ke Bukhara pada zaman pemerintahan Al-Amir Nuh bin Mansur dan tinggal di perkampungan kecil di Bukhara yang bernama Khirmitan. Namun akhirnya beliau menetap di Afsyanah kerana berhampiran dengan tempat kerjanya. Sejak kecil beliau telah memperlihatkan kepintarannya yang cemerlang dan kemajuan yang luar biasa dalam menerima pendidikan. Ibnu Sina kecil yang tangkas mula belajar al-Quran pada usia 5 tahun. Sejak usia lima tahun itu Ibnu Sina telah mendapatkan pendidikan al-Quran dan sastera dari ayahnya. Pada usia sepuluh tahun ia sudah hafal al-Quran, menguasai ilmu sastera, tasawuf, dan geometri. Belum genap usia 16 tahun, Ibnu Sina sudah menguasai ilmu perubatan. Semasa itulah dia bermula merawat pesakit. Segala kerja kerasnya selama ini berhasil. Ketekunannya dalam mempelajari pelbagai disiplin ilmu menjadikannya pakar dalam berbagai ilmu.
Kemudian nama Ibnu Sina mula dikenali ramai orang. Bahkan di negeri jiran pun, beliau menjadi bahan perbualan.Ramai orang dari negeri jiran datang berjumpa beliau untuk berbincang. Berduyun-duyun penduduk dari berbagai negeri datang untuk berguru dan berubat pada beliau. Ibnu Sina tak pernah berhenti belajar demi mengembangkan keilmuannya. Walaupun selalunya dia tertidur kelelahan. Di usia 17 tahun, di tengah usahanya untuk menyembuhkan penyakit baginda Nabi Nuh bin Mansur, ia terus mengembangkan ilmunya. Sebagai penghargaan raja atas jasanya yang berjaya menyembuhkan raja. Baginda meminta Ibnu Sina menetap di istana, sekurang-kurangnya untuk sementara semasa raja dalam proses penyembuhan. Tapi Ibnu Sina menolaknya dengan halus, sebagai gantinya ia hanya meminta izin untuk mengunjungi sebuah perpustakaan kerajaan yang kuno dan antik. Siapa sangka, dari sanalah ilmunya yang luas ditambah lagi semangat belajarnya yang tinggi. Ia tidak pernah melewatkan waktu sedikitpun untuk bermalas-malasan. Beberapa karyapun telah dilahirkan. Selama 1,5 tahun Ibnu Sina jarang tidur, penuh dengan berbagai ilmu dan analisa. Semangat belajarnya kuat sekali. Ibnu Sina selalu memikirkan ilmu yang sedang dipelajarinya sampai ia memahaminya. Ibnu Sina tidak hanya belajar teori tetapi juga mempraktikkannya. Pengalaman ilmunya terhadap apa yang dipelajari semakin luar biasa.
Ibnu Sina tak pernah berhenti belajar. Ilmunya semakin matang dan mendalam. Pada usia 21 tahun, Ibnu Sina berjaya membuat buku pertamanya, Al-Majmu ‘ketika berada di Khawarazm yang mengandungi berbagai ilmu pengetahuan yang lengkap. Beliau menyelesaikannya berdasarkan semua disiplin ilmu yang dipelajarinya. Ketika terjadi kekacauan di Kerajaan As-Samani, Ibnu Sina mula melakukan pengembaraan. Beliau keluar dari Bukhara menuju Karkang. Dari situ beliau berpindah ke Jarjan dan Khurasan. Namun demikian, pada akhirnya Ibnu Sina meninggalkan kedua-dua negara tersebut menuju ke Dahastan. Setelah itu, Ibnu Sina kembali ke Jarjan dan bertemu dengan Juzjani. Di Jarjan, Ibnu Sina menjadi menteri sebanyak dua kali. Meski demikian, beliau tidak pernah berhenti menulis, mengajar, dan mengarang. Malam hari, beliau mengajar dan pagi hari beliau bertolak ke pejabat Kementerian tempat beliau tugaskan. Buku yang ditulis Ibnu Sina lebih kurang 250 judul, termasuk kitab, esei, dan artikel dalam bidang matematik, mantik, akhlak, fizik, perubatan dan falsafah.
“>Ibnu Sina
Buku-buku yang pernah dikarang oleh Ibnu Sina, dihimpun dalam buku besar Essai de Bibliographie Avicenna yang ditulis oleh Pater Dominician di Kaherah. Karya-karya beliau semasa hidupnya antara lain:
1. Kitab Al Majmu ‘, tentang ilmu pengetahuan yang lengkap ditulis saat beliau berusia 21 tahun.
2. Kitab Asy-Syifa, (The Books of Recovery / The Books of Remedy), tentang cara-cara rawatan beserta ubatnya (18 jilid). Kitab ini di dunia perubatan menjadi ensiklopedia falsafah perubatan. Dalam bahasa latin kitab ini dikenali dengan nama “Sanatio”.
3. Kitab Al Qanun Fit Thibb (Canon of Medicine). tentang cara rawatan yang sistematik (16 jilid). Memuatkan kenyataan yang tegas bahawa darah mengalir terus-menerus dalam suatu lingkaran dan tidak pernah berhenti. Buku ini sejak zaman Dinasti Han di China telah menjadi rujukan standard karya-karya perubatan cina.
Photobucket
Bab Mata dalam buku Qanun at thib.
4. Kitab Remedies for the Heart, mengandungi sajak-sajak. Mengandung sajak-sajak perubatan yang menghuraikan tentang 760 jenis penyakit beserta cara pengubatannya.
5. Kitab An Najah, tentang falsafah.
6. Penemuan tentang anatomi tubuh. Ibnu Sina percaya bahawa setiap tubuh manusia terdiri daripada empat unsur iaitu tanah, air, api dan angin. Keempat unsur itu memberi sifat lembap, sejuk, panas, dan kering serta sentiasa bergantung pada unsur lain yang terdapat pada alam ini.
7. Penemuan tentang rawatan psikomosaik. Beliau mengembangkan ilmu diagnosis melalui denyutan jantung (pulse diagnosis) untuk mengetahui secara pasti keseimbangan emosi seseorang dalam beberapa saat.
8. Penemuan di bidang kimia tentang logam. Beliu menerangkan bahawa benda-benda logam sebenarnya berbeza antara satu dengan yang lain secara khusus. Setiap logam membentuk dengan sendirinya dengan pelbagai jenis. Beliau dianggap penerus dari perkembangan ilmu kimia yang telah dirintis oleh Jabir Ibnu Hayyan (Bapa Kimia Muslim Pertama).
9. Penemuan di bidang geografi tentang asal usul lembah.
10. Penemuan tentang peredaran darah. Beliau mendapati bahawa “Darah mengalir terus menerus dalam suatu lingkaran dan tidak pernah berhenti.”
11. Kitab Fi Aqsamil Ulumil Aqliya (On the Division of the Rational Sciences) tentang pembahagian ilmu-ilmu rasional.Kitab An Nayat (Book of Deliverence) buku tentang kebahagiaan jiwa (merupakan sebuah buku psikologi.
12. Kitab Risalah As Siyasah (Book of Politics) tentang politik.
13. Penemuan di bidang bahan perubatan.
14. Penemuan dalam bidang psikoterapi.
15. Kitab Al Musiqa, tentang muzik.
16. Kitab Al Mantiq, tentang logik. Buku ini dipersembahkan untuk Abu Hasan Sahil.
17. Kitab Uyun Al Hikmah (10 jilid) tentang falsafah. Ensiklopedio Britanica menyebutkan bahawa kemungkinan besar buku ini telah hilang.
18. Kitab Al Hikmah El Masyriqiyyin, tentang falsafah timur.
19. Kitab Al Insyaf tentang keadilan sejati.
20. Kitab Al Isyarat Wat Tanbihat, tentang prinsip ketuhanan dan sembahyang.
21. Kitab Al Isaguji (The Isagoge), tentang logik
22. Kitab Fi Ad Din (Liber de Mineralibus) tentang mineral.
23. Kitab Al Qasidah Al Aniyyah, tentang prosa.
24. Kitab Sadidiya, tentang perubatan.
25. Kitab Risalah At Thayr, tentang karangan roman.
26. Kitab Danesh Nameh, tentang falsafah.
27. Kitb Mujir. Kabir Wa Saghir, tentang dasar-dasar ilmu logik secara lengkap.
28. Salama wa Absal, Hayy ibn Yaqzan, al-Ghurfatul Gharabiyyah (Pengasingan di Barat) dan Risalatul Thayr (Risalah Burung).
Ibnu Sina
Karya Ibnu Sina Berupa Kitab Al Qanun Fit Thibb (Canon of Medicine) telah digunakan sebagai buku teks perubatan di pelbagai universiti di Perancis. Misalnya di Sekolah Tinggi Perubatan Montpellier dan Louvin yang telah menggunakannya sebagai bahan rujukan pada abad ke-17 M. Sementara itu, Prof. Phillip K. Hitti telah menganggap buku tersebut sebagai “Ensiklopedia Perubatan”. Buku ini telah membincangkan serta membahas tentang penyakit saraf. Arahan tersebut juga membahas cara-cara pembedahan yang menekankan tentang keperluan pembersihan luka. Bahkan di dalam buku-buku tersebut juga dinyatakan keterangan dengan lebih jelas disamping gambar-gambar dan sketsa-sketsa yang sekaligus menunjukkan pengetahuan anatomi Ibnu Sina yang luas.
Penulis-penulis barat telah menganggap Ibnu Sina sebagai “Bapa Perubatan” kerana beliau telah menggabungkan teori perubatan Yunani Hipocrates dan Galen dan pengalaman dari ahli-ahli perubatan dari India dan Parsi serta pengalaman beliau sendiri, Ibnu Sina meninggal pada tahun 1073, semasa kembali ke kota yang disukainya Hamadhan. Walau beliau sudah meninggal, namun berbagai ilmunya sangat berguna dan digunakan untuk penyembuhan berbagai penyakit yang kini diderita umat manusia.
Beliau sudah tiada, tapi akan selalu menemani kita. Sekarang, kita harus meneruskan setiap karyanya. Jangan sampai kita hanya boleh bernostalgia dengan membaca sejarah beliau. Ikrarkan dalam hati bahawa “Kita boleh seperti beliau, beliau boleh begitu juga kita”. Jangan kita hanya kagum sahaja tapi kita tidak mahu menggali ilmu yang beliau tinggalkan. Sebab ilmu yang beliau tinggalkan tidak kita pergunakan dan kembangkan dengan baik. Malah, orang barat yang mengembangkannya. Sudah masanya kita bangkit dan kita capai kegemilangan islam dengan ilmu pengetahuan serta iman dan taqwa.
credit to tranungkite
Subscribe to:
Posts (Atom)