Password encryption: rationale and Java example
Where has your password been?
Most of the web sites today have some sort of a registration module where a user is asked to choose a username/password combination. This data gets stored in the database. You might wonder if the password you provide will be kept well-protected (read encrypted). In case you are the person designing such backend registration component, why not give your users peace of mind by encrypting their passwords?
One-way hash encryption
This scenario is a perfect candidate for "one-way hash encryption" also known as a message digest, digital signature, one-way encryption, digital fingerprint, or cryptographic hash. It is referred to as "one-way" because although you can calculate a message digest, given some data, you can't figure out what data produced a given message digest. This is also a collision-free mechanism that guarantees that no two different values will produce the same digest. Another property of this digest is that it is a condensed representation of a message or a data file and as such it has a fixed length.
There are several message-digest algorithms used widely today.
Algorithm Strength
MD5 128 bit
SHA-1 160 bit
SHA-1 (Secure Hash Algorithm 1) is slower than MD5, but the message digest is larger, which makes it more resistant to brute force attacks. Therefore, it is recommended that Secure Hash Algorithm is preferred to MD5 for all of your digest needs. Note, SHA-1 now has even higher strength brothers, SHA-256, SHA-384, and SHA-512 for 256, 384 and 512-bit digests respectively.
Typical registration scenario
Here is a typical flow of how our message digest algorithm can be used to provide one-way password hashing:
1) User registers with some site by submitting the following data:
username password
jsmith mypass
2) before storing the data, a one-way hash of the password is created: "mypass" is transformed into "5yfRRkrhJDbomacm2lsvEdg4GyY="
The data stored in the database ends up looking like this:
username password
jsmith 5yfRRkrhJDbomacm2lsvEdg4GyY=
3) When jsmith comes back to this site later and decides to login using his credentials (jsmith/mypass), the password hash is created in memory (session) and is compared to the one stored in the database. Both values are equal to "5yfRRkrhJDbomacm2lsvEdg4GyY=" since the same password value "mypass" was used both times when submitting his credentials. Therefore, his login will be successful.
Note, any other plaintext password value will produce a different sequence of characters. Even using a similar password value ("mypast") with only one-letter difference, results in an entirely different hash: "hXdvNSKB5Ifd6fauhUAQZ4jA7o8="
plaintext password encrypted password
mypass 5yfRRkrhJDbomacm2lsvEdg4GyY=
mypast hXdvNSKB5Ifd6fauhUAQZ4jA7o8=
As mentioned above, given that strong encryption algorithm such as SHA is used, it is impossible to reverse-engineer the encrypted value from "5yfRRkrhJDbomacm2lsvEdg4GyY=" to "mypass". Therefore, even if a malicious hacker gets a hold of your password digest, he/she won't be able determine what your password is.
Java code that implements one-way hash algorithm
Let's assume that you are writing a web application to be run in a servlet container. Your registration servlet might have the following portion (for clarity, I ommitted input validation steps and assume that a password value was passed in within the password form input field):
[...]
public void doPost(HttpServletRequest request, HttpServletResponse response)
{
User user = new org.myorg.registration.User();
user.setPassword(org.myorg.services.PasswordService.getInstance().encrypt(request.getParameter("password"));
[...]
Here is the definition of my PasswordService class that does the job of generating a one-way hash value:
package org.myorg.services;
import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import org.myorg.SystemUnavailableException;
import sun.misc.BASE64Encoder;
import sun.misc.CharacterEncoder;
public final class PasswordService
{
private static PasswordService instance;
private PasswordService()
{
}
public synchronized String encrypt(String plaintext) throws SystemUnavailableException
{
MessageDigest md = null;
try
{
md = MessageDigest.getInstance("SHA"); //step 2
}
catch(NoSuchAlgorithmException e)
{
throw new SystemUnavailableException(e.getMessage());
}
try
{
md.update(plaintext.getBytes("UTF-8")); //step 3
}
catch(UnsupportedEncodingException e)
{
throw new SystemUnavailableException(e.getMessage());
}
byte raw[] = md.digest(); //step 4
String hash = (new BASE64Encoder()).encode(raw); //step 5
return hash; //step 6
}
public static synchronized PasswordService getInstance() //step 1
{
if(instance == null)
{
instance = new PasswordService();
}
return instance;
}
}
The method of interest here is encrypt(). I chose to make this class a singleton in order to ensure that there is only one instance of it at any given time to avoid concurrency issues and conflicts between generated hash values. For an explanation of this design pattern, try a google search for "java singleton pattern".
Let's step through the code above to see what's going on:
step 1: The registration servlet will interface with our PasswordService class using this static getInstance() method. Whenever it is invoked, a check will be made to see if an instance of this service class already exists. If so, it will be returned back to the caller (registration servlet). Otherwise, a new instance will be created.
step 2: We are asking Java security API to obtain an instance of a message digest object using the algorithm supplied (in this case, SHA-1 message digest algorithm will be used. Both SHA and SHA-1 refer to the same thing, a revised SHA algorithm). Sun JDK includes JCA (Java Cryptography Architecture) which includes support for SHA algorithm. If your environment does not support SHA, NoSuchAlgorithmException will be thrown.
step 3: Feed the data:
a) convert the plaintext password (eg, "jsmith") into a byte-representation using UTF-8 encoding format.
b) apply this array to the message digest object created earlier. This array will be used as a source for the message digest object to operate on.
step 3: Do the transformation: generate an array of bytes that represent the digested (encrypted) password value.
step 4: Create a String representation of the byte array representing the digested password value. This is needed to be able to store the password in the database. At this point, the hash value of the plaintext "jsmith" is "5yfRRkrhJDbomacm2lsvEdg4GyY=".
step 5: Return the String representation of the newly generated hash back to our registration servlet so that it can be stored in the database. The user.getPassword() method now returns "5yfRRkrhJDbomacm2lsvEdg4GyY="
That's all. Your database password data is now encrypted and if an intruder gets a hold of it, he/she won't have much use of it. Note, you have to consider how you will handle "forgot password" functionality in this case as you now cannot simply send a password to the user's email address. (Well, you should not be doing things like that anyway) . Sounds to me like a perfect topic for my next article.
Monday, December 21, 2009
uml diagrams
UML Diagram for Bank Management System
Posted by Ramana
BANK MANAGEMENT
(Mini-project)
Ramana K
Use Case Modeling
Use Case diagram for Banking System:
1. Online Transaction - use case specifications
1.1 Brief Description
Account transaction begins when customer is successfully logged in to the site. Several menus where displayed related to profile of customer and the recent transactions and the currentaccount balance.
The main purpose of using online account transactions is to transfer cash from one account to another for this purpose the customer is provided fields to specify the accounts to which he is transferring amount. After everytransaction a confirmation is displayed to customer.
The customer is also provided the possibility to change the account login password, but not the user id, every transaction is added to the bank database.
Flow of Events
1.2 Basic flow
1. User enters username and password.
2. Bank Database validates the user.
3. On success user can transfer money, change his password and view his profile.
1.3 Alternate Flow
If in the basic flow, the details specified by user are invalid then he is informed that his login is failed .Then the user may quit the system or he may create a newaccount.
1.4 Pre Conditions
The user should have a valid account in the bank.
1.5 Post Conditions
The account database is modified after transaction.
2. Client Desktop transaction- Use case specifications
2.1 Brief Description
Client desktop is given to each of bank employees and they are provided with account logins with a user id and a password. Every employee switches on his desktop and login to his account through which he can communicate with bank database.
An employee can have operations like withdrawal of money, giving loans, furnishing the DD/cheque and customers may want to deposit money.
Bank employee is allowed to modify the database accordingly. And the intended services are provided to the customers.
Flow of Events
2.2 Basic flow
1. Employee enters his username and password.
2. Bank Database validates the employee.
3. On success employee can withdraw or deposit money, issue loans and
DD/cheque to the customers.
2.3 Alternate Flow
If in the basic flow, the details specified by employee are invalid the he is informed that his login is failed .Then the person is not employee of the bank and he is not having authority to perform those actions.
2.4 Pre Conditions
The employee must possess a account login and password.
2.5 Post Conditions
The account database is modified after transaction. Employee issues dd/cheque to user.
3. Login- Use case specifications
3.1 Brief Description
The online customer or a bank employee has to login to access their accounts from bank database. A vendor is provided for communication with bank’s database and this vendor provides safety and atomicity. A user may be an invalid user so the system has to prompt the person appropriately.
Flow of Events
3.2 Basic flow
1. User enters username and password.
2. Bank Database validates the user.
3. On success user can precede the transaction.
3.3 Alternate Flow
If in the basic flow, the details specified by user are invalid the he is informed that his login is failed.
3.4 Pre Conditions
The user must possess a login id and password.
3.5 Post Conditions
None.
4. Logout- Use case specifications
4.1 Brief Description
The person who ever logged in to the system or bank database has to logout after all the work is over. The vendor provided for communication is now closed from database.
Flow of Events
4.2 Basic flow
1. User clicks the logout
2. All the transactions he performed are reflected in the bank database.
4.3 Alternate Flow
If in the basic flow, if the internet connection is lost user must refresh the page again.
4.4 Pre Conditions
The user should have been logged in already.
4.5 Post Conditions
None.
5. Invalid Login- Use case specifications
5.1 Brief Description
If a person with a invalid user id or password details want login to the system, the system has to prompt the person about failure and should not open the vendor of communication until he furnishes valid user id & password.
Flow of Events
5.2 Basic flow
1. User enters username and password.
2. Bank Database validates that the login is invalid.
3. Further he may not be allowed to proceed until enters a valid login.
5.3 Alternate Flow
1. If the user enters a valid login he must be allowed to proceed further.
5.4 Pre Conditions
None.
5.5 Post Conditions
None.
6. Card transaction - Use case specifications
6.1 Brief Description
Card transaction includes a credit/debit card. This service is provided by a retail institution to a card holding customer. The customer may want to buy any thing form merchant, customer provides the card and the merchant stripes the card into the card reader then it is checked for validity and if the card is valid the transaction begins. A credit card will have a credit amount you can deduct amount more than that. A debit card will be having some level of funds if the funds are over thetransaction will not continue.
Flow of Events
6.2 Basic flow
1. The retailer places the card in card reader.
2. Card reader checks the card validity after that retailer asks the customer
to enter pin number.
3. After entering the pin number retailer enters amount to be paid by customer.
4. Card reader proceeds transaction after that it updates bank Database
and finally gives a receipt to customer.
6.3 Alternate Flow
If in the basic flow, if the card or pin is invalid or the account don’t have sufficient balance the card reader ejects the card out by giving a receipt.
6.4 Pre Conditions
The User must possess a debit/credit card.
6.5 Post Conditions
The user has to sign in the receipt and put a copy of receipt with him for security reasons.
7. ATM transaction- Use case specifications
7.1 Brief Description
If a customer approaches an ATM, the person is requested to insert card. After inserting the card it is checked for validity if the card is valid transaction continues. And then pin validation is done; if the pin is invalid the transaction is doesn’t allowed. The customer may have transactions like checking balance, draw amount and donation. If there are less funds thetransaction is sustained.
Flow of Events
7.2 Basic flow
1. User inserts card in ATM.
2. Bank Database validates the card.
3. On success employee must enter pin and select from his list of services
appeared on the screen.
7.3 Alternate Flow
If in the basic flow, the card or pin is invalid a receipt ejects out from ATM in response to the error.
7.4 Pre Conditions
The User must possess an ATM card
7.5 Post Conditions
The user must take the receipt.
8. Insert card - Use case specifications
8.1 Brief Description
The customer is requested to insert (swipe) card and the card is taken in and kept inside for the whole transaction time. Once the transaction is over card is spelled out
Flow of Events
8.2 Basic flow
1. Customer inserts card in ATM or Card reader
2. ATM or Card reader validates the card.
3. On success user can precede the transaction
8.3 Alternate Flow
If the card is invalid, ATM ejects the card or then it may be taken back from Card reader and gives a receipt indicating the error number.
8.4 Pre Conditions
The User must possess an ATM card or else a debit/credit card.
8.5 Post Conditions
None.
9. Invalid card - Use case specifications
9.1 Brief Description
The card inserted will be checked for validation. The card may not be inserted properly or it may be out of date or it can be an invalid for specific bank. In those situations it is requested for re-insert.
Flow of Events
9.2 Basic flow
1. Customer inserts card in ATM or swipes in Card reader.
2. ATM (Card reader) validates the card is invalid.
3. Customer must re-insert (swipe) the card again.
9.3 Alternate Flow
Even after reinserting the card, if the card is invalid ATM (Card reader) gives a receipt indicating that the card is invalid.
9.4 Pre Conditions
The User must possess an ATM card or a credit/debit card.
9.5 Post Conditions
None.
10. Pin validation - Use case specifications
10.1 Brief Description
After inserting the card and if it is checked for validation, the user is requested for pin. The pin is itself present on magnetic strip on back of card and it is checked with the entered one.
Flow of Events
10.2 Basic flow
1. Customer inserts card in ATM and enter his pin number.
2. ATM validates the pin.
3. On success user can precede the transaction
10.3 Alternate Flow
If the pin is invalid, ATM ejects the card and gives a receipt indicating
the error number.
10.4 Pre Conditions
The User must possess an ATM card.
10.5 Post Conditions
None.
11. Invalid Pin - Use case specifications
11.1 Brief Description
The pin entered may be wrong in that case transaction is cancelled. The customer is requested for re-inserting of card and re-entry of pin. The number of wrong trials may be limited according to bank’s specifications.
Flow of Events
11.2 Basic flow
1. Customer inserts card in ATM and enter his pin number.
2. ATM founds that pin is invalid.
3. The customer requested to reinsert card or reenter the pin.
4. In case the number of trials exceeded, ATM blocks the card temporarily.
11.3 Alternate Flow
If customer enters a correct pin transaction proceeds further.
11.4 Pre Conditions
The User must possess an ATM card.
11.5 Post Conditions
The user should not enter the pin number more than the number of trials.
Class Diagram for Banking System:
Sequence Diagrams
and
Collaboration Diagrams
Online Transaction Sequence Diagram:
Online Transaction Collaboration Diagram:
Client desktop Transaction Sequence Diagram:
Client desktop Transaction Collaboration Diagram:
Login & Logout Sequence Diagram:
Login & Logout Collaboration Diagram:
ATM Transaction Sequence Diagram:
ATM Transaction Collaboration Diagram:
Card Validation Sequence Diagram:
Card Validation Collaboration Diagram:
Pin Validation Sequence Diagram:
Pin Validation Collaboration Diagram:
Web merchant Transaction Sequence Diagram:
Web merchant Transaction Collaboration Diagram:
Activity Diagrams
Online Transaction Activity Diagram:
Client Desktop Transaction Activity Diagram:
ATM Transaction Activity Diagram:
Web Merchant Transaction Activity Diagram:
Component Diagram for Banking System:
Deployment Diagram for Banking System:
All The Best Guys !!!
Ramana.K
Posted by Ramana
BANK MANAGEMENT
(Mini-project)
Ramana K
Use Case Modeling
Use Case diagram for Banking System:
1. Online Transaction - use case specifications
1.1 Brief Description
Account transaction begins when customer is successfully logged in to the site. Several menus where displayed related to profile of customer and the recent transactions and the currentaccount balance.
The main purpose of using online account transactions is to transfer cash from one account to another for this purpose the customer is provided fields to specify the accounts to which he is transferring amount. After everytransaction a confirmation is displayed to customer.
The customer is also provided the possibility to change the account login password, but not the user id, every transaction is added to the bank database.
Flow of Events
1.2 Basic flow
1. User enters username and password.
2. Bank Database validates the user.
3. On success user can transfer money, change his password and view his profile.
1.3 Alternate Flow
If in the basic flow, the details specified by user are invalid then he is informed that his login is failed .Then the user may quit the system or he may create a newaccount.
1.4 Pre Conditions
The user should have a valid account in the bank.
1.5 Post Conditions
The account database is modified after transaction.
2. Client Desktop transaction- Use case specifications
2.1 Brief Description
Client desktop is given to each of bank employees and they are provided with account logins with a user id and a password. Every employee switches on his desktop and login to his account through which he can communicate with bank database.
An employee can have operations like withdrawal of money, giving loans, furnishing the DD/cheque and customers may want to deposit money.
Bank employee is allowed to modify the database accordingly. And the intended services are provided to the customers.
Flow of Events
2.2 Basic flow
1. Employee enters his username and password.
2. Bank Database validates the employee.
3. On success employee can withdraw or deposit money, issue loans and
DD/cheque to the customers.
2.3 Alternate Flow
If in the basic flow, the details specified by employee are invalid the he is informed that his login is failed .Then the person is not employee of the bank and he is not having authority to perform those actions.
2.4 Pre Conditions
The employee must possess a account login and password.
2.5 Post Conditions
The account database is modified after transaction. Employee issues dd/cheque to user.
3. Login- Use case specifications
3.1 Brief Description
The online customer or a bank employee has to login to access their accounts from bank database. A vendor is provided for communication with bank’s database and this vendor provides safety and atomicity. A user may be an invalid user so the system has to prompt the person appropriately.
Flow of Events
3.2 Basic flow
1. User enters username and password.
2. Bank Database validates the user.
3. On success user can precede the transaction.
3.3 Alternate Flow
If in the basic flow, the details specified by user are invalid the he is informed that his login is failed.
3.4 Pre Conditions
The user must possess a login id and password.
3.5 Post Conditions
None.
4. Logout- Use case specifications
4.1 Brief Description
The person who ever logged in to the system or bank database has to logout after all the work is over. The vendor provided for communication is now closed from database.
Flow of Events
4.2 Basic flow
1. User clicks the logout
2. All the transactions he performed are reflected in the bank database.
4.3 Alternate Flow
If in the basic flow, if the internet connection is lost user must refresh the page again.
4.4 Pre Conditions
The user should have been logged in already.
4.5 Post Conditions
None.
5. Invalid Login- Use case specifications
5.1 Brief Description
If a person with a invalid user id or password details want login to the system, the system has to prompt the person about failure and should not open the vendor of communication until he furnishes valid user id & password.
Flow of Events
5.2 Basic flow
1. User enters username and password.
2. Bank Database validates that the login is invalid.
3. Further he may not be allowed to proceed until enters a valid login.
5.3 Alternate Flow
1. If the user enters a valid login he must be allowed to proceed further.
5.4 Pre Conditions
None.
5.5 Post Conditions
None.
6. Card transaction - Use case specifications
6.1 Brief Description
Card transaction includes a credit/debit card. This service is provided by a retail institution to a card holding customer. The customer may want to buy any thing form merchant, customer provides the card and the merchant stripes the card into the card reader then it is checked for validity and if the card is valid the transaction begins. A credit card will have a credit amount you can deduct amount more than that. A debit card will be having some level of funds if the funds are over thetransaction will not continue.
Flow of Events
6.2 Basic flow
1. The retailer places the card in card reader.
2. Card reader checks the card validity after that retailer asks the customer
to enter pin number.
3. After entering the pin number retailer enters amount to be paid by customer.
4. Card reader proceeds transaction after that it updates bank Database
and finally gives a receipt to customer.
6.3 Alternate Flow
If in the basic flow, if the card or pin is invalid or the account don’t have sufficient balance the card reader ejects the card out by giving a receipt.
6.4 Pre Conditions
The User must possess a debit/credit card.
6.5 Post Conditions
The user has to sign in the receipt and put a copy of receipt with him for security reasons.
7. ATM transaction- Use case specifications
7.1 Brief Description
If a customer approaches an ATM, the person is requested to insert card. After inserting the card it is checked for validity if the card is valid transaction continues. And then pin validation is done; if the pin is invalid the transaction is doesn’t allowed. The customer may have transactions like checking balance, draw amount and donation. If there are less funds thetransaction is sustained.
Flow of Events
7.2 Basic flow
1. User inserts card in ATM.
2. Bank Database validates the card.
3. On success employee must enter pin and select from his list of services
appeared on the screen.
7.3 Alternate Flow
If in the basic flow, the card or pin is invalid a receipt ejects out from ATM in response to the error.
7.4 Pre Conditions
The User must possess an ATM card
7.5 Post Conditions
The user must take the receipt.
8. Insert card - Use case specifications
8.1 Brief Description
The customer is requested to insert (swipe) card and the card is taken in and kept inside for the whole transaction time. Once the transaction is over card is spelled out
Flow of Events
8.2 Basic flow
1. Customer inserts card in ATM or Card reader
2. ATM or Card reader validates the card.
3. On success user can precede the transaction
8.3 Alternate Flow
If the card is invalid, ATM ejects the card or then it may be taken back from Card reader and gives a receipt indicating the error number.
8.4 Pre Conditions
The User must possess an ATM card or else a debit/credit card.
8.5 Post Conditions
None.
9. Invalid card - Use case specifications
9.1 Brief Description
The card inserted will be checked for validation. The card may not be inserted properly or it may be out of date or it can be an invalid for specific bank. In those situations it is requested for re-insert.
Flow of Events
9.2 Basic flow
1. Customer inserts card in ATM or swipes in Card reader.
2. ATM (Card reader) validates the card is invalid.
3. Customer must re-insert (swipe) the card again.
9.3 Alternate Flow
Even after reinserting the card, if the card is invalid ATM (Card reader) gives a receipt indicating that the card is invalid.
9.4 Pre Conditions
The User must possess an ATM card or a credit/debit card.
9.5 Post Conditions
None.
10. Pin validation - Use case specifications
10.1 Brief Description
After inserting the card and if it is checked for validation, the user is requested for pin. The pin is itself present on magnetic strip on back of card and it is checked with the entered one.
Flow of Events
10.2 Basic flow
1. Customer inserts card in ATM and enter his pin number.
2. ATM validates the pin.
3. On success user can precede the transaction
10.3 Alternate Flow
If the pin is invalid, ATM ejects the card and gives a receipt indicating
the error number.
10.4 Pre Conditions
The User must possess an ATM card.
10.5 Post Conditions
None.
11. Invalid Pin - Use case specifications
11.1 Brief Description
The pin entered may be wrong in that case transaction is cancelled. The customer is requested for re-inserting of card and re-entry of pin. The number of wrong trials may be limited according to bank’s specifications.
Flow of Events
11.2 Basic flow
1. Customer inserts card in ATM and enter his pin number.
2. ATM founds that pin is invalid.
3. The customer requested to reinsert card or reenter the pin.
4. In case the number of trials exceeded, ATM blocks the card temporarily.
11.3 Alternate Flow
If customer enters a correct pin transaction proceeds further.
11.4 Pre Conditions
The User must possess an ATM card.
11.5 Post Conditions
The user should not enter the pin number more than the number of trials.
Class Diagram for Banking System:
Sequence Diagrams
and
Collaboration Diagrams
Online Transaction Sequence Diagram:
Online Transaction Collaboration Diagram:
Client desktop Transaction Sequence Diagram:
Client desktop Transaction Collaboration Diagram:
Login & Logout Sequence Diagram:
Login & Logout Collaboration Diagram:
ATM Transaction Sequence Diagram:
ATM Transaction Collaboration Diagram:
Card Validation Sequence Diagram:
Card Validation Collaboration Diagram:
Pin Validation Sequence Diagram:
Pin Validation Collaboration Diagram:
Web merchant Transaction Sequence Diagram:
Web merchant Transaction Collaboration Diagram:
Activity Diagrams
Online Transaction Activity Diagram:
Client Desktop Transaction Activity Diagram:
ATM Transaction Activity Diagram:
Web Merchant Transaction Activity Diagram:
Component Diagram for Banking System:
Deployment Diagram for Banking System:
All The Best Guys !!!
Ramana.K
Subscribe to:
Comments (Atom)
.jpg)