Usecase:
Alice goes to obscura.tld and presses create secure chat
Alice inputs her name and the password for the chat
Alice enters the chat, and is given an url to share with Bob
Bob goes to url, enters name and same password as alice
Alice and Bob shares a private conversation.
When both log out the chat is destroyed.

Design considderations:
The encryption scheme used is AES in Counter mode of operation as implemented here http://www.movable-type.co.uk/scripts/aes.html
All encryption/decryption is performed in javascript to keep keys clientside.
When a chat is created, a salt is generated based on microtime + some pseudorandom numbers
The salt is sent to the clients
All encryption/decryption is performed against the password+salt
When Alice (chat owner) enters the chat, she sends a SHA1 hash (computed locally in javascript) of her password+salt to obscura. This is saved to the chat
When Bob tries to enter chat he sends a SHA1 hash of his password+salt. If this matches the one supplied by Alice he's allowed in, else he is denied.

Why i think this is secure:
The keys never leave the clients
The only thing kept in the central DB are encrypted messages and a SHA1 of the password+salt for any given chat
Even if someone got access to the messages circumventing the authentication, they'd need the password to read them.

I'll release the source code under a GNU v.3 when time comes.
What have i missed here? What are the security pitfalls? Do i need ssl/https? (since everything that leaves/enters the client are already encrypted)