Skip to main content

Password Security Recommendations

User credential / Password Security.

Recent security related embarrassment at Yahoo, LinkedIn and Sony has only proved that securing user information needs more considerations. Security is not a product rather a process.

First identifying how username/password can be leaked and its price.

Basically there are four ways an adversary can find out username/password for one or more accounts stored on the server.

 1. Password guessing - Assuming adversary knows username for one or more accounts and they can
      deploy dictionary attack to find correct password.

 2. Adversary eavesdropping on user network ( Man in Middle Attack)

 3. Adversary getting access to user computer through some virus/worm

 4. Adversary getting access to username/password table or system on the server.

Password Guessing :

Fix :
  Max invalid attempts strategy should be deployed, i.e. temporary lock the account after 4 or 5 invalid password attempt.
Cons :
  Inconveniences to user, user will endup locking and changing passwords frequently
  Attacker can easy mass lock accounts using DOS (block such IP's)
Note: Encrypting passwords at server side or securing Servers will not save one from this attack.

Man in Middle Attack :
Fix :
   Enable SSL/TLS (HTTPS) minimum 128 bits, this will take care of message security and integrity.
Note : Any secure system should function on TLS otherwise it will send all communication in plain text  and this communication will be freely available to everyone in middle (Local Network, ISP etc)

Key-logger / Worm :

Adversary can easily get access to username/password via installed keylogger/worm/virus on a user computer.
Fix : Application should email notify or track user logins from all IP's and alert user whenever a new IP is used.

DB Leak

  Adversary can get access to database containing one or more username/password either through electronic hack, or through an unhappy employee or physical server room job.

This is major embarrassment! destroys organization brand, value and trust.

Fix :
  Salt and Hash both Username/Password (i.e. one way encryption). Random salts should be stored on a separate system other than where username/passwords are stored.

These were the very high level things one needs to consider when designing security strategy.

If you are interested more details evaluations feel free to contact me on LinkedIn.


Popular posts from this blog

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax.

Example 1: Stores list of Strings in an Entity

public class Users implements Serializable {

    private static final long serialVersionUID = 1L;
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private List<String> certifications = new ArrayList<String>();

    public Long getId() {
        return id;

    public void setId(Long id) { = id;

    public List<String> getCertifications() {
        return certifications;

    public void setCertifications(List<String> certifications) {
        this.certifications = certifications;

        Users u = new Users();
        u.getCertifications().add("Sun Certified Java Programmer");

Generated Tables

Column --> ID
    Row             1


ArrayList vs LinkedList vs HashSet Performance Comparision

ConclusionsInserting & Reading sequentially from Collection prefer LinkedList/ArrayListInserting & Reading/Deleting by Search/equals from Collection prefer HashSetInserting, ArrayList & LinkedList performs best while HashSet takes double the timeReading, HashSet performs best while ArrayList & LinkedList are marginally lessDeleting, HashSet performs 10 times better than ArrayList & ArrayList performs 4 times better than LinkedList. LinkedList is slow because of sequencial search Bottom line : unless you are not going to iterate using for(Integer i : list ) then prefer HashSet
Inserting/Reading/Deleting integer's from zero till countJDK7Collectionactioncounttime msArrayListInsert1000/1LinkedListInsert1000/1HashSetInsert1000/1ArrayListInsert100005LinkedListInsert100004HashSetInsert100007ArrayListInsert10000011LinkedListInsert10000011HashSetInsert10000021ArrayListGet/Read1000LinkedListGet/Read1000HashSetGet/Read1000ArrayListGet/Read100004LinkedListGet/Read100003Has…

Validating CSV Files

What is CsvValidator ?
  A Java framework which validates any CSV files something similar to XML validation using XSD.

Why should I use this ?
  You don't have to use this and in fact its easy to write something your own and also checkout its source code for reference.

Why did I write this ?
  Some of our projects integrate with third party application which exchanges information in CSV files so I thought of writing a generic validator which can be hooked in multiple projects or can be used by QA for integration testing.

What is the license clause ?

Are there any JUnit test cases for me checkout ?
 Yes, source

How to integrate in my existing project ?

Just add the Jar which can be downloaded from here CsvValidator.jar and you are good.

Instantiate CsvValidator constructor which takes these 3 arguements

         // filename is the the file to be validated and here is a sample         // list - defines all the fields in the above csv file ( a field has index, type, isOptional, rege…