How NOT to Store Passwords! - Computerphile

Security of users' passwords should be at the forefront of every web developer's mind. Tom takes us through the insecure ways in which some websites deal with passwords.
Note: At circa 8mins, the animation does not show how the 'salt' is also stored in the database alongside the username.
Hashing Algorithms and Security: • Hashing Algorithms and...
Security of Data on Disk: • Security of Data on Di...
More from Tom Scott: / enyay and / tomscott
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computerphile is a sister project to Brady Haran's Numberphile. See the full list of Brady's video projects at: bit.ly/bradychannels

[@lucabutbi]

"You might be watching this years in the future"

[@IVIaskerade]

Just remember that nothing you can code is secure against the xkcd approach to password cracking - you find the user and beat it out of them.

[@martinkunev9911]

IVIaskerade I don't actually know some of my passwords (I only remember how to move my fingers to write them). So that makes it a little harder unless there is a keyboard nearby :)

[@frtard]

IVIaskerade They don't call it 'rubber-hose cryptanalysis' for nothing...

[@giantdad1661]

frtard I know that, Bahahaha that tactic is just too funny. Lol, I'm not |\/|askerade, by the way XD

[@Catlord98765]

Thanks for the advise! I changed my youtube password from 12345 to 54321!

[@chillinchum]

***** should we try logging in as you then?

[@Catlord98765]

chillin chum Please don't! You will see all my private videos detailing all my privater information. Like how my name is Jesse Parker and I live in Canada, Alberta.

[@chillinchum]

***** I don't know if your being serious, but if you are, sorry, I'm only joking. XP maybe I should have made that more clear, oops.

[@craigcodlin5249]

+Catlord just subscribed bro :-)

[@AyeAyeKane]

Once I played a game years ago, forgot my password in about 2 months so I clicked Forgotten password? And it told me to put in my old password.

[@dolebiscuit]

Always put salt on your hashbrowns.

[@mattressjpg]

I am watching this years in the future, how did he know?

[@spelunkerd]

The first time a website emailed my password back to me with no security, I was astounded. Thanks for a glimpse behind the curtain, to understand the stupidity of people who design web systems.

[@gingersndragons]

just have your password 'incorrect' so if you get it wrong it will say " your password is incorrect" and then you will remember

[@phizzhead53]

i hate that sites wont let me make a password that has more than 20 caracters and say i cannot use symbols

[@schybba]

When aliens attack the Earth and we are all doomed, I want the world leaders to choose this guy to go on TV and explain to everyone why we are screwed.

[@jorenko]

Something else important: The vast majority of hashing algorithms are VERY FAST! They've been designed that way to make document signing easy. So in addition to salting, you also generally want to repeat the hash recursively, for a few thousand rounds, or generally whatever takes 1/10 - 1/4 of a second. The longer you can make it take, the longer it will take an attacker to crack as well.

[@runescaper1333]

Wow I didnt know youtube hides when you type your password. mine is ********** haha

[@boumbh]

Shit, my password is "my_dogs_name"... Now I need to change again...

[@boumbh]

MidnightSlash. I changed for "safe_password".

[@TheRandomRandomizer]

boumbh Good idea, it's better than "unsafe_password".

[@boumbh]

strontiumXnitrate This one is actually not so bad...

[@cakeman58]

OK, please clarify that last method. You say at 7:45 about the salt "a new second password if you like that goes in the database". But if I understand this correctly, you're storing only the salt and the resulting hash, not the user's password, right? When a user logs back in, you take the password they provide and the stored salt and see if its hash matches the stored hash. Is that correct?

[@Merobieboy]

Shit, i just store my passwords in my HTML code!!

[@rich1051414]

There's also 'pepper'. 'Salt' and 'Pepper'. Salt is a known random mutation string unique to the user, then the pepper is another unique mutation string unique to the database itself, but stored SEPARATE from that database, so that it is a secret to the database, with nothing linking the two together in any way.

[@bluelunala]

man the time gap between comments when sorting by new is amazing

[@ZipplyZane]

Websites that refuse to store their own passwords are actually a pet peeve of mine. I don't think you should do that. It forces people to link their account to another identity. Nothing wrong with offering the option, but it shouldn't be required. Facebook is the worst, BTW, since the identity it links you to is usually your real life identity. And a major part of security online is being anonymous. So even if something does get cracked, it doesn't link directly to you in real life, allowing you the ability to create a new online identity.

[@zerobyter]

7:54 but then how can you compare the salted password when the user wants to login or something??

[@RickYorgason]

Ah, a couple things here could have been clearer in the infographics. First, the database with the salted hash should have had *four* columns: user_number, user_name, salt, and salted_hash. Second, the process of hashing a salted password isn't a complicated black box where you input the salt and the password and get out a salted hash. It's actually quite simple: if your password is my_dogs_name and your salt is m8jz6psqYc, then your salted password is my_dogs_namem8jz6psqYc. Just throw that into your hashing algorithm to get your salted hash.

[@RickYorgason]

Taiiwo Llort Yo dawg, I heard you like rainbow tables. You wouldn't actually need a rainbow table of rainbow tables. Your rainbow table just needs to include every password with every possible salt attached to the end. Of course, since salts can be arbitrarily long and complex, that's impractical. You are right that salting does nothing to make brute force attacks more difficult, but brute force attacks are already pretty difficult. Even if you have access to a password database, you could be spending a day per password with a brute force attack. With a rainbow table, on the other hand, you could get hundreds of thousands of passwords almost instantly.

[@TaiiwoLlort]

Skrapion Rainbow tables only make the creation of the tables easier by removing the need to generate random strings for each hash, and instead getting strings from previously created hashes. You'd need a table where the first cell in each row would contain a random string of a given parameter set (length and character set). Within each cell would be salt, and a rainbow table with every hash using that salt. The next cell in that row would use an algorithm to generate another valid salt with the same parameters from the cell to it's left, this is really simple, but the more efficiently it can be done, the better. Each row would have different parameters for the salt, which would allow the user to search for a salt set with a given parameter set. Reducing such a tiny computation in a project as large as this seems almost poinless, but combined with the benefits to search time make it a really efficient solution.

[@ChosenOne41]

ah geez, better change my password to password2 then

[@mihiguy]

Nice video! One more addition: If you are implementing something like this today, try to use a hash algorithm that is not easily parallelizable (like MD5 or SHA-1 is) - graphics cards can crack these quite fast nowadays - and use one that supports a "rounds" parameter - basically a way to make a hash slower (and also make cracking it slower), so that it is possible to easily increase the password strength later when computers get faster, without hogging up your server today for 5 seconds whenever someone logs in. Good choices (as of end of 2013) are PBKDF or BCrypt. And if you increase the security of an existing website by replacing unsalted (or just SHA-1 salted) hashes with more secure ones, re-hash any old passwords you find when the user logs in (and not only when he changes his password), because at that time you have the cleartext password and can re-hash it. Lots of people will not change their password often and that will put their passwords at higher risk if they are still stored in a more insecure hashed format.

[@Kie-7077]

I really don't want to sign in with Facebook or Google etc, they are privacy nightmares and it is none of their business what webpages I am signing in to (yes I block Google analytics etc).

[@emilskukojs3783]

safest place to store a password? a piece of paper under your pillow

[@AbhimanyuAryan]

watched this while eating food. Usually I watch small funny episodes. Plan to watch these video every day while eating something. Knowledge is power

[@OwenPrescott]

the universal password solution... password123456 problem solved.

[@molotera8789]

5:08 do i hear a kitty?

[@TheRomichou]

Dear ComputerPhile, thank you for finding people like this guy who can explain stuffs so well and make you want to learn even more. I don't know much about web security, but with the past videos on the subject, and with this remarkable guy, things are getting clear. If not already one, he would be a great teacher. So thank you again for making this video!

[@PMW3]

1,23,4,5,6 that's the worst password ever that sounds like what an idiot would have on his luggage!

[@Leito339]

The current standard (2013-14. May even be outdated now?) is to use Bcrypt. Why? MD5 and SHA1 take milliseconds to create a hash, while Bcrypt allows you to set the time complexity. For example you can set Bcrypt to create a password in 0.5s. Assuming md5 can hash 1,000,000 per second, and Bcrypt 2 per second, you've now HUGELY slowed down any attempt to brute force your passwords.

[@SleeplessRonin]

6+ years in future. Video still being watched.

[@KethusNadroev]

If the salt is random then there would be no way to compare the two passwords unless the salt is also stored. Isn't stealing all the users passwords and salts the same as stealing their passwords and secret questions then?

[@blakkcooper]

You know a nerd by his emotionality towards topics most people don't even understand on a basic level.

[@ThisNameIsBanned]

Well this episode was fairly entertaining, especially as it has a connection to an event right at the moment of time. Really really cool, 10/10 want more of that.

[@jugbrewer]

Hey Brady, I'm glad you put links to the extra videos at the end in the description, since you can't click the ones inside the video frame on a phone. Keep doing that!

[@Truthiness231]

Mmm, salted hash... I should probably take a break from the internet and eat if this video made me hungry...

[@duelmonitor]

Two other important additions: 1) hash password with salt first 2) apply a key stretching to an end user's password prior to sending up to the server. This ensures that even common passwords like "123456" take a long time computationally to crack instead of trying a quick pass over the database to discover all users with a "123456".

[@MrCyanGaming]

Ok, but how do you compare the password once you've added this huge random string to it?

[@FedePohl]

"You might be watching this years in the future" Yeah 10 years later, hope this aged well.

[@Hendlton]

I've had websites email me my password when I asked for it...

[@Snowlovers]

It's 2022 and I just had to email this video to a large multinational corporation because when I clicked "Forgot my password" on their site, they emailed me back MY PASSWORD!

[@user-uc9fm8bn9o]

I would like to see more videos from this person. I've watched every video of this channel with him talking and they are all very fascinating. Please give us more!

[@muhammed.s5468]

I loved the energy of this guy, the spirit of the video, and the explanation. The way he said "You might be watching this years in the future" I liked it (:

[@AsbjornGrandt]

If I'm ever asked for my password, I'll just tell them "I, D, the number ten, T"

[@mequable]

In my country there's a debate going on about internet voting in general, and it's seriously considered. Estonia has implemented e-voting and electronic government and is always used as an example of "successful" e-voting system. I've read a bunch of articles proclaiming hashing (alone) as an "unbreakable" way of encrypting data. I'm glad I can see that video too, and compare.

[@alonmln]

Amazing video. In my opinion, this is the best Computerphile presentor yet.... He is so passionate it's watching :)

[@superraiden]

Computerphile is by far one of my favourite KZbin channels! Keep up the god work!

[@Robstar0]

It's a big pity that it wasn't explained more in-depth how salting works. Like how you can used your salted hash to verify someones password. I looked it up, and the solution is that the salt is also stored in the database and added to the typed-in password every time a login is tried. So at 8:18 it should have shown an extra field; That of the salt.

[@cyphardotcom]

Actually, you can store the salt in the same field as your hash. And you also define the hashing function in the hash too. It's a standard format used on Unixes specifically designed to be future proof. It looks like $$$$$

[@Robstar0]

cyphardotcom Thanks for the insight!

[@kofY84]

Important note is that you should use salt + some hashing algorithm that takes relatively long to encrypt that password string. Like 1 second long. This way, even brute force attack will take, as you said, forever. But using hashing algorithm like MD5 that takes less than 0,001 s is no problem for brute force, since you can try all the combinations for 6 letter password in like 40 seconds.

[@gamingminion4199]

"You might be watching this year's in the future"- Me watching 10 years later..... Yes

[@danobot12]

This guy is awesome! The way he explains things is really good! I hope we'll see him more often :)

[@darthsavage4025]

Somebody should show this video to the folks at Sony...

[@annihilatorg]

There should also be a mention of key stretching. By re-applying the salt and re-encrypting the hash a large number of times, it becomes linearly more computationally difficult to brute force a collection of password hashes. You can require 1000+ times more computational work per single password attempt. Of course, this means every log-in from a user would also require 1000+ times more work to authenticate.

[@HorseyWithNoNamey]

I love all the videos with this guy. He's so passionate about it

[@alexfortune9716]

Okay, absolutely brilliant ;) Once again you show class Tom, altho I always preferred adding the encryption layer over the salthash layer whenever I could. Looking forward for more!

[@kylone1]

The important thing to note for salted passwords is that the same salt has to be used to verify a password. The current standard is using a keyed hashing algorithm with per-password salt. You have to store the salt so that the same salt can be added to an entered password to compare it to the stored (salted) hash. The salt's purpose is to make it harder for an attacker to work backwards from the (salted) hash to the password--it does nothing to prevent random password guessing. Other things that you can do are using other pieces of information (ip address, google authenticator, a code texted to a phone, etc.) as something in addition to the password for logins.

[@arturk9181]

i store passwords in .txt file on server. That good?

[@_nadie0]

uhhh I'm watching it in the middle apocalypse of 2020.

[@Nadox97]

"And if Ive just said either of your KZbin passwords go change it." Made me laugh way too hard.

[@edwardkiel3496]

It's funny I was just watching this the other day, since news broke today that one of the major telecomunications companies in Iceland had been hacked into, and information about over 70 thousand people compromised (nearly 1/4 of Iceland's total population) and posted online. Not only had the company stored a massive amount of text messages unencrypted, but a huge number of passwords also, UNencrypted! Basicly the passwords in one column, names in the next, then email addresses, phone numbers, social security numbers etc. And this is one of major corporations in Iceland, totally unencrypted ... only two minuted into this video and they would have realised their stupidity ...

[@StarLink149]

I still think this is one of the best videos to ever be published by Computerphile.

[@damirdze]

Thank you sir , I am just working on a project and I would do the research probably finding out myself but you explained it perfectly and direction saving me a lot of time. Really like to watch your channel.

[@GummieI]

So you saying I should change my youtube password from 123456 to 1234567? :P

[@arnokeesman6247]

0:58 "you may be watching this years in the future" yeah I am lol

[@Rocksteady8519]

How could i not watch this video in the future? xD

[@farmeryaeg]

I really like watching Computerphile videos with Tom Scott

[@achillepellissier8136]

Tom Scott is really great, wish we'll see him in more videos in the future Brady! :)

[@TomaszWota]

There's a mistake at the beginning - you can't actually tell if a website stores your password in plain text in db just because they offer to send it to you on demand. It could very well be encoded with a two-way algorithm. Now, I'm not saying it's a good idea, but it doesn't mean it's there in db in plain text - you can't actually tell. (One could argue that it's almost as if it was in plain text - because if someone grabs your source code and db, they will be able to decipher passwords)

[@IamGodseye]

from future still this holds true

[@nimal5429]

dayum 9 years and its still so useful

[@andromeda4641]

this is cool,you learn so many things by these guys,keep up the good work.

[@darkivn]

I'm now "years into the future" - how amazing!

[@BenjaminAlexander]

Interesting that the best approach is what UNIX /etc/passwd files have used since 1988 or 1990 (though with smaller salt). Also interesting that the method used by repo.org.cz (first and only place I've seen it) which uses ssh keys wasn't mentioned at all. With this method, the password is assigned (or generated) to be a long random string (for security) but the user isn't required to remember it. Instead it is stored locally in a keychain, protected by a the user's local password.

[@LordMegatherium]

Correct me if I'm wrong but a browser in a vanilla state doesn't have the capability to manage ssh keys on a keychain.

[@BenjaminAlexander]

Megatherium I wouldn't know. However, I will say that I use a Mac, and the builtin Keychain Access integration with Safari is a pretty good substitute. It still alows users to pick bad passwords, but it's not scary to use a different (and 'strong') password on every website. The only thing nicer would be better (easier) auto creation of passwords. Also, I had to buy an app (which may not be neccessary anymore now that keychains can be stored in iCloud) to sync the passwords to my mobile device. This makes me think of an even better (and in retrospect, glaringly obvious) system: the one-time passwords that my banks makes me use to access their sites. I have credit card sized hardware to generate them for one bank, and two different apps for access to the two others.

[@jakx2ob]

Most webbrowsers support client certificates, haven't seen hardly any site using them for authentification.

[@maxhorowitz-gelb5358]

Yeah but what if the user loses their private key on their harddrive?

[@roemelvs]

could you elaborate on this repo.org.cz method a bit more? Or perhaps point me to a tutorial?

[@AlphasysNl]

Glad to know that the Hash and Salt method is still considered pretty good practice. Many webshops and forum systems use it.

[@Domsmudge]

Love Tom's videos on this channel!

[@OmegaCraftable]

When a user tries to get into their account with a salted hash system, how does it compared the entered password with the salted and hashed password stored in memory?

[@darkseraph2009]

Question about salt: seeing as every username will have its own random salt, the salt must be stored somewhere as well. How is it that, even if someone manages to get the salted hash and the user's salt that they're unable to reconcile the two in order to find the original password string? I'm sure something about the way the salt and hashing algorithm work makes it impossible to deconstruct, but I have little idea as to the mechanics behind it.

[@Jrez]

I don't even know why I'm subbed to this channel, I know nothing about computers and I never really grasp what they are talking about on any significant level.

[@DavidXNewton]

I had a great one from a Quality Inn website - not only did it store my password in plain text, but it helpfully displayed it on the screen in my profile when I logged in!

[@lorenzo501]

if every key from hashing is different (the proper hash salt way..) how does the system check if the input/password is correct? since they can't store the key because that would be just as insecure then how the heck is this possible..??

[@deerie3490]

'You may be watching this *years* in the future.' _Chokes on tea_ No way!

[@evjow]

Fantastic. Already seen this many many times, because it's so easy to understand and kind of funny

[@pebre79]

The best explanation on passwords I've ever seen. excellent

[@WorldBeneathYourFeet0]

This guy is a great educator.

[@LucaMasters]

He says we know people use method 1 because they send the plaintext password to the user on requestio, but that happens with encryption too. (However, I suspect that many are using plaintext.) Anyway, his answer isn't quite good enough. Make sure your hash is intentionally slow. We can calculate 200 000 000 MD5sums (which is also partially broken) per second with a good consumer computer. If you use iterated bcrypt, it takes, well, depends on the interations, but if it takes a second, logging in now takes an extra second of server time, but cracking a password takes 1 second * the number of attempts. So don't just use salt and a secure hash. Use salt and SLOW hash. (Probably bcrypt.) Also, if you do avoid doing this on your own and integrate Google and Facebook logins, please use Persona or something similarly decentralized. I give all my data to Google, but not everyone wants to, and they (and I) probably shouldn't.

[@majoro7251]

Thanks for the two tips man, especially the slow hash one. Also, adding pepper to the slow salted hash would make things better :p

[@Sukuraidogai]

***** Making a slow hash is great if you have an array of servers with decent computational power, but you can basically achieve the same effect by waiting 3 seconds before you validate the password and return the network response. This is assuming you're not worried that anyone is going to hack into your database, which if you're a small operation that doesn't have a lot of servers and doesn't have a lot of internal people looking at your database, you can pretty much guarantee this.

[@Sukuraidogai]

Scott Gartner I don't think you understand. If it takes a split second to guess at a password, brute force attempts become feasible. Brute force is pretty much the only method hackers use. If you increase the time between attempts to a couple seconds, it will take lifetimes to guess the password.

[@DarthGhitza]

Scott Gartner How would brute force (meaning generating all the passwords and trying them out probably using some backtracking algorithm) work on websites that block the account after a given number of consecutive fails... let's say 5? Let's say my password was 123456... then the backtracking would try 123451, 123452, 123453, 123454,123455 and then it gets blocked just before trying 123456 which is actually the password. It wouldn't even get to 123451, because it would start with 111111 then 111112 and so on. It would probably get blocked after 111115. Of course this is an extreme example and not all backtracking algorithms necessarily generate stuff in alphabetical order... but I trust you get the point. If you limit the number of consecutive fails, brute force becomes useless.

[@sgartner]

DarthGhitza The assumption throughout this conversation is that the bad guy has been able to get a copy of your database. The methods we are talking about are intended to be used directly against the database, not via a web application. In fact, the bad guy might get the source code to the application as well, but if the algorithm is truly secure that won't afford him any significant benefit in cracking passwords.

[@matts.1352]

I once took part in a website design and programming competition for high-school kids, where part of the judges rubric was security. I went on to win 2nd place, but the method I used to secure my site was much stronger than what all the other contestants offered. The method I used was to store the time a user signed up as en epoch date, along with their username (which was less-extensively hashed) and soon-to-be-hashed password. I then used that epoch time as a seed in a psuedo-random number generator that I modified for custom results, created a random 16-character string from that generator using the seed, then used that string as the salt. The hash algorithm I used is a 256bit SHA-2 hash. For the username, I simply hashed it with the epoch itself. I didn't want to worry too much about the usernames, but wanted just enough security so that an intruder doesn't know both the username or password, only the epoch time they signed up at. I'm not sure how secure that method in general is, but I feel the whole method overall was overkill, though it works. I also like the method I used more than some alternatives, because you aren't storing the salt, rather a value used to make the salt. I had another layer of security to combat knowing the algorithm itself used to make the salt and hash the password. That next layer is what I describe in the next two paragraphs, and you don't have to read it as it isn't exactly related to the video. The epoch-to-salt generator and password-hashing is compiled code that the web-server program I used would run during each login. The code itself was as secure as I could make it as well. It has warnings checked, so that they can't use warnings to figure out parts of the code. I stripped all tables and used no strings, so they can't visually and easily identify parts of the code. I also added dead-end and false-alarm code, so that reading the instructions of the reverse engineered code will give stray as well as real instructions. That way, even if they managed to access the code behind my web-server as well as the database, they would still have to figure out how to decompile, reverse engineer, and read the instructions of the code itself. I know from experience with decrypting and reading the instruction sets of iOS apps that it isn't too difficult for a dedicated person to do just that, but it still adds to the tasks and difficulty that many hackers wouldn't deal with (on a very un-related note, I like to hack, hook onto, and inject my own code into iOS apps, so that I can add new features to games and apps myself). In all, the only way for a hacker to have figured out the passwords from users was to either go through the steps to reverse engineer the code, brute-force the hash algorithm, or monitor what the user types in the password box using a program on their computer. The reverse engineering option is way out of the picture, as that would require bypassing other security layers to retrieve the code in the first place, as well as the added security padding I put in the code. Brute-forcing the hash algorithm would take an immensely long time for a computer to do, and hardly any look-up tables exist for 256-bit SHA-2, especially extensive enough to figure out the salted passwords. Last, programs on someones computer that monitor the passwords they use aren't really the fault of my website, and anyone using any website is susceptible to programs like that.

[@apocalipsenerd]

My favorite computerphiler

[@laytonmiller5865]

This is like saying: "Its hard so don't even try". Actually, you actually DO say that (00:24). So by that logic, we shouldn't even be programming. Or driving cars. Or playing sports. Or being alive. Indeed, I say the opposite - TRY. Just learn before you do. It's not even hard to set up secure password storage, if you know how to read, because google returns (approx) 71,500,000 results when you type in "secure password storage". Of course, knowing anything whatsoever about secure application design, firewalls, encryption, and other super basic internet security concepts is a must. Skilled surgeons are skilled surgeons because they paid attention. Same applies to everything else in life.

[@arturoagal]

I'm watching this years in the future!

[@DaveMeowington]

Alright time for a random question: Does the *comma* have any use in sentences that are in English?

[@degso0]

One of the best videos I've seen on this channel.

[@tobiass.9361]

"years in the future" - i guess he was right

[@EdwinFairchild]

if a salted hash contains random characters then how is the user authenticated each time? I kind of don't understand how that would work

[@fergochan]

Jordan Johnson Given that everybody keeps replying with the same thing I assume it's happening to everybody...

[@ArrayPro]

Eddie Amaya The salt is always the same, so the algorithm always returns the same hash.

[@bigcheesetaste]

Eddie Amaya The salt could be something like join date or (as mentioned in the video) the username. Just some random string that anyone can see. It doesn't matter if they can because hashing is a kind of one-way encryption. It is simply added to the start of the password prior to hashing. It forces attackers into using a brute force approach as things like rainbow tables become useless, and there are no duplicate hashes in the table :)

[@stensoft]

bigcheesetaste Username is not random therefore it is not good salt. It helps against some attacks but proper random string is much better.

[@MightyGoldenBoy]

I love the videos with this guy. He's great

[@juandig]

Thanks for the great advice, I'm gonna use this without doing any more recent research, I'm sure things haven't changed much in the meantime

[@dino130395]

But if the salt is totally random, and not based on something like the username, then how do you validate the login the next time?

[@NickRoman]

And if this stuff is interesting, listen to the Security Now podcast with Steve Gibson. He talks every week about the Adobe flubs and the NSA spying, etc. and explains this type of thing also, and many other fun topics.

[@pratham5383]

i am looking at it after 5 years of upload

[@flidrl]

When I first time tried making a web with login - just my experimenting with web - I already started on hashing (MD5) the password, I never did plain-text or encryption. Nowadays I upgraded to SHA1 plus using salt. True, not completely random salt, but based on each users data, thus different to everyone.

[@uusikaytaja10]

I like to use the password incorrect, since if i forget it the page will say "Your password is incorrect".