i want to implement this soon.
maybe using this code (which is bsdl):
http://pajhome.org.uk/crypt/md5/sha1src.html
maybe using this code (which is bsdl):
http://pajhome.org.uk/crypt/md5/sha1src.html
that guy is pretty cool too, and he likes one of my favorite artists!
by the way. the following users should heavily consider using a stronger password set and having a system of password use.
analytics ********a
Chiken ********3
jason ********x
jathrox ********e
maple ********r
Mathew ********e
Ozntz ********1
sriehl ********a
tc ********e
now these passwords are stored in an encrypted SHA1 hash the passwords are known only to ozntz who cracked the passwords (while crack may not be the preferred term by some it's generally referred to as cracking passwords ).
The method he used was to do number crunching on a rainbow table . If anyone is interested in the methodology or the software involved you can check out a few more of these sources. Here's a link to the software used for developing the tables, as well as cracking the actual password. If you have theoretical interest in the method rainbow tables use that optimizes efficiency of table lookup time check here
Here's a link about how to choose strong passwords and a local one about password management systems per asemisldkfj!
Hopefully this does nothing to the trust around here with the site passwords. All passwords are recorded in those SHA1 hashes though, so if you'd like to make a stronger password it's very much encouraged so that if it so happened that someone were to get access to the database and then the hashes, that they may not be able to determine your password using a cryptanalysis attack like rainbow tables, or be able to brute force your password against the hash.
by the way. the following users should heavily consider using a stronger password set and having a system of password use.
analytics ********a
Chiken ********3
jason ********x
jathrox ********e
maple ********r
Mathew ********e
Ozntz ********1
sriehl ********a
tc ********e
now these passwords are stored in an encrypted SHA1 hash the passwords are known only to ozntz who cracked the passwords (while crack may not be the preferred term by some it's generally referred to as cracking passwords ).
The method he used was to do number crunching on a rainbow table . If anyone is interested in the methodology or the software involved you can check out a few more of these sources. Here's a link to the software used for developing the tables, as well as cracking the actual password. If you have theoretical interest in the method rainbow tables use that optimizes efficiency of table lookup time check here
Here's a link about how to choose strong passwords and a local one about password management systems per asemisldkfj!
Hopefully this does nothing to the trust around here with the site passwords. All passwords are recorded in those SHA1 hashes though, so if you'd like to make a stronger password it's very much encouraged so that if it so happened that someone were to get access to the database and then the hashes, that they may not be able to determine your password using a cryptanalysis attack like rainbow tables, or be able to brute force your password against the hash.
and it's not just if they get access to the database. it's anyone who can sniff your wire. here's the way that ttf authentication works:
login with user name and password. this sends a request to the server that includes your password in clear text. the server then sets a cookie on your system with your user_id and your password hashed in SHA-1. each subsequent ttf page that you visit sends your cookie information to the server, which includes your password hashed with SHA-1.
so basically, each time you login, your password goes on the wire in clear text. every other time you load a page on ttf, your password is sent hashed with SHA-1.
so if you're like me, you'll send your password in clear text once a month, but you'll send it hashed with SHA-1 maybe around 2,000 times a month. so it is unlikely that someone will sniff your clear text password (although possible), but it's much more likely that someone will sniff your SHA-1 hash.
so use 8 characters or more, and it will be extremely difficult for them to guess your password based on the hash.
i plan to use this javascript code above to hash your password when you login before it even hits the wire. so your password will always be hashed in SHA-1 on the wire. but that doesn't mean anything if you're using a short password that is easily guessable based on the hash.
login with user name and password. this sends a request to the server that includes your password in clear text. the server then sets a cookie on your system with your user_id and your password hashed in SHA-1. each subsequent ttf page that you visit sends your cookie information to the server, which includes your password hashed with SHA-1.
so basically, each time you login, your password goes on the wire in clear text. every other time you load a page on ttf, your password is sent hashed with SHA-1.
so if you're like me, you'll send your password in clear text once a month, but you'll send it hashed with SHA-1 maybe around 2,000 times a month. so it is unlikely that someone will sniff your clear text password (although possible), but it's much more likely that someone will sniff your SHA-1 hash.
so use 8 characters or more, and it will be extremely difficult for them to guess your password based on the hash.
i plan to use this javascript code above to hash your password when you login before it even hits the wire. so your password will always be hashed in SHA-1 on the wire. but that doesn't mean anything if you're using a short password that is easily guessable based on the hash.