Issues with your account? Bug us in the Discord!
Politicians have competitors in stupidity
E.T
Quote-o-matic
in Zocalo v2.0
More precisely admins of some forums and society sites...
[url]http://www.f-secure.com/weblog/archives/00001293.html[/url]
Some places even saved user passwords in plaintext!
Using old antique software versions with safety features generally turned off and built-in holes allowing getting access to user account table is equally bad despite passwords being hashed...
Because plain MD5 hash is joke against brute force attack if passwords are are short and simple! So I would keep "salting" / extra data insertion before hashing as reasonable minimum safety requirement.
Isn't it nice thought that to get somekind security password has to be at least ten characters long and contain also capitals, numbers and special characters and you have to remember it without storing it everywhere...
And that after all this some dummy can destroy it all by running software so that passwords are saved as plaintext? :D
[url]http://www.f-secure.com/weblog/archives/00001293.html[/url]
Some places even saved user passwords in plaintext!
Using old antique software versions with safety features generally turned off and built-in holes allowing getting access to user account table is equally bad despite passwords being hashed...
Because plain MD5 hash is joke against brute force attack if passwords are are short and simple! So I would keep "salting" / extra data insertion before hashing as reasonable minimum safety requirement.
Isn't it nice thought that to get somekind security password has to be at least ten characters long and contain also capitals, numbers and special characters and you have to remember it without storing it everywhere...
And that after all this some dummy can destroy it all by running software so that passwords are saved as plaintext? :D
Comments
Or that software was last time up to date during stone age and is full of unpatched security holes allowing nice little SQL injections?
Now if the assumption is that passwords are not even slightly similar to dictionary words, reversing MD5 should still be way out of the league of most attackers. Of course, if a password is a dictionary word, then a nice dictionary attack will reverse an unsalted MD5 real quick.
So adding salt to generate randomness is very advisable, and beyond that, if there's a chance of using a CPU-expensive password based key derivation function (e.g. it won't hog the server royally) perhaps it's worth using so any attacker with the database in their hands can enjoy the feeling of every try taking 5 seconds to compute. Attackers still outside the gates should of course be locked out after enough incorrect tries.
But, using dictionary words as the basis of passwords is not sensible either. One should assume however that many users won't bother setting secure passwords, and make the most of what they can be convinced to set.
I personally assume that any proxied session can be conveniently hijacked (and inserted crazy shit into, so if the browser is vulnerable, that ends the day) unless it's end-to-end encrypted and authenticated. With the strong reminder that a fashionable tool called Tor is NOT end-to-end (the fun which ensured when one guy bothered to demonstrate what exit nodes can do, was also mentioned in the F-Secure article) and thus without HTTPS, it amounts to losing security to gain anonymity.
I also assume that most sites will be hacked eventually... and thus I employ per-site passwords, which are rather distant from a valid word in any language - and won't bear the slightest resemblance to a local user account, database or disk decryption password anywhere at all.
1. Make sure you're running over HTTPS (specifically SSL3, as SSL1 and SSL2 have been broken) with preferably at least 128 bit (IE6 only supports up to 128 bit; other browsers go higher).
2. Use a strong hash method for storing passwords. Something like SHA256 which is one of the strongest hashes that most languages innately support. Don't use an encryption function unless you need to reverse the password - but don't forget, if you use an encryption function, a hacker can also decrypt it if they have access to your server and grab everyone's password. If you can give a SALT, good, otherwise adding garbage to the password before save is good (obviously you have to store the SALT and/or garbage in the DB associated with the user - so a hacker might be able to figure out how to use this with enough code analysis).
3. If you're storing passwords in a database, make sure you have set up the code to block SQL injection attacks. Might take some effort to review the code, but VERY important if you care about password security. Even one "oops" can compromise your entire database.
4. Strong passwords are good (number + letter + symbol) but they are only as good as the storage algorithm. On a lot of weak algorithms, such as MD5, you'll find many passwords correspond to the same MD5 value. Similarly, once hashed, the goal you are looking for is uniqueness. If a hacker breaks one password and yours is the same, and there is no garbage and there is no salt, then they immediately know every other person that is the same password.
Even with "strong" passwords, you're still working with a fairly limited character set. A standard keyboard has about 100 characters available. If the password uses ASCII character sets, there are still 140 or so characters (after dropping system command characters) available to use that no one ever uses. Using symbols and numbers only increase your pool by about 50 (to 100) characters. While that's a lot, there are still a LOT of characters that no one ever uses in passwords, and thus a LOT fewer characters that thieves have to guess at.
5. The most important: NEVER EVER tell your passwords you want secure to anyone. The exceptions would be a family member that needs to be able to access stuff in an emergency; a coworker that is using a common shared system with a shared password; or access to a common home computer. But NEVER tell a secure personal password to a stranger, an IT tech, a friend, or anything else.
By "secure personal password" I mean any password you use on a site where someone can do something as you: a personal website; your bank account; your online retailers; etc. Even forums should fall under this category. Why? What if an acquaintance drops onto Firstones and starts writing nasty stuff about your boss and then tells your boss, "go look at what I found!" And the most important one to watch out for: when you have trouble logging onto a system and IT support asks, "What's your password," you NEVER give it. You can type it in (but make sure they aren't watching the keys you type).
6. Which leads into "and if you are in IT support:" (a) don't ask someone their password; (b) if they type it in, avert your eyes; and (c) if they tell you without you asking, inform them on password security and that they should NOT tell anyone their password.
7. Unguessable passwords: Never use a password that someone that knows you can guess. For instance, I should never use [B]Purple@@rdvark[/B] - it's too guessable. But [B]a*8jf6^l[/B] would be fine (if you can remember it!). However, using words with symbol replacement is a good idea IF you can think of ones that wouldn't obviously be associated with you. For instance, [B]Fir_$t0nes[/B] might be good. The inserted character in a nonstandard (but logical) position means that even if someone guesses I used Firstones, they are more unlikely to guess the password. The key is the right balance between "Oh, that person lives on 123 Left-Right St." and their password is "123Left-Right" (which satisfies strong password criteria!) but is 100% guessable to anyone with half a brain, and the pure random type that no one will be able to remember. If you can memorize a few pure random passwords, all the better for you, because hackers will have a harder time penetrating your passwords.
8. Rememberable passwords: Never use passwords you have to write down. You can write a hint, such as "the P password" if you have trouble remember which password for which site. While Sleepy's idea of every site gets it's own password is good, there is no way you can remember that many passwords and which sites get which passwords without writing them down. And if you write them down, then all someone has to do to get into all your accounts is break into your house. That's not good security either.
I personally use a series of passwords that I cycle between different sites. Some I consider more secure than others, and some less. Those less secure usually go to forums. Those more secure go to financial sites and online retailers. If someone breaks one of my passwords they can get into more than one site, true, but the number of sites is quite limited each. Similarly I use a different username on every site. That means they have to know both which sites I used the password they broke, and which username I use on each site.
Another trick I use is a standard password but for odd sites such as "Site XYZ: Q password without symbols" or "Site ABC: C password without last two numbers" - you get more variations of your passwords without having to truly remember a new password and without having to write down anything a thief might be able to use.
9. Enforcing strong passwords: Why should sites enforce strong passwords? Lets say someone with the username "Spaceballs" uses the password "Spaceballs" which is entirely too guessable. Well, someone guesses it and also manages to find a SQL injection to grab your whole DB. Now they know what the password is and what the crypted/hashed value is. All they have to do (especially if you don't use SALT or appended garbage) is simply run every known hashing and encryption algorithm until they find the one you use. Then it's just a matter of time before they can grab other passwords from the system (because who cares about brute force "3 tries and you can't log in" methods when you have the DB on your own server with no restriction to guesses!). Yes, by knowing your encryption algorithm and having your DB file, they no longer need to have access to the server to try and break other passwords. And all they needed was one very weak password, a little luck, and a SQL hole.
--RC
[QUOTE=Random Chaos;165913]9. Enforcing strong passwords: Why should sites enforce strong passwords? Lets say someone with the username "Spaceballs" uses the password "Spaceballs" which is entirely too guessable. Well, someone guesses it and also manages to find a SQL injection to grab your whole DB.[/QUOTE]If someone manages to grab whole user DB it really doesn't matter much are passwords easy to guess if they are short and not protected with other means than hashing.
Oh, guess what has been most common password in leaked data basing to statistics gathered by one person...
"salasana" which is password in Finnish! (200+)
Other lot favoured passwords are 12345, 123456, perkele and qwerty.
Though number of password=username cases might surpass these...
"Why, that's the pin on my luggage." :D
Regarding "pure" brute force, with no assumptions about the password's content or length, I would still tend to think "nah, likely isn't practical yet".
But thanks for reminding, I didn't realize there existed methods which are halfway between a classic dictionary attack and brute force. One of the popular ones seems to be called [url=http://en.wikipedia.org/wiki/Rainbow_table]rainbow tables[/url].
That method was described as currently practical for MD5 hashes where source passwords have length up to 8 characters. It can apparently combine the benefits of dictionary and brute force attacks, but it eats memory for breakfast, lunch and dinner.
Testing a fairly good MD5 [url=http://md5.thekaine.de]"search engine"[/url] (operator unknown, so nobody should test their super-secret password against it :D ), I found indeed that it was relatively decent. Obtaining MD5 sums like 'echo -n "someword" | md5sum', I tried the following:
sp00 - reversed
fl4rn - reversed
f00bar - reversed
f00bar3d - fail
f1shf4rm - fail
fishfarm - reversed
fiShfarM - fail
fiShIes - fail
f1Sh - fail
fISh - fail
sHriMp - fail
00ps - reversed
(I guess the guys didn't generate a full-featured rainbow table, since mis-capitalization seems their weakness.)
Spaceballs? :rolleyes:
Also someone must have been trolling with great gusto... I don't think 514007 would be otherwise 63 times in leaked list.
This must be the most descriptive password ever: idiootti
I think you can figure its English equal without help and it was used by multiple people. :D
User: Spaceballs
Pass: MajorA$$hole
--------
On another note, and still within the realm of stupidity and the general brain implosion principles, one cannot ignore this function:
[url]http://worsethanfailure.com/Articles/Division-By-Zero,-Solved-Yet-Again.aspx[/url]
8. Rememberable passwords: Never use passwords you have to write down. You can write a hint, such as "the P password" if you have trouble remember which password for which site. While Sleepy's idea of every site gets it's own password is good, there is no way you can remember that many passwords and which sites get which passwords without writing them down. And if you write them down, then all someone has to do to get into all your accounts is break into your house. That's not good security either.
--RC[/QUOTE]
An important part of good data security is good physical security. Securing your passwords if you have them written down for others to access critical information in the even of your incapacitation can be important. (especially i it contains information you need disseminated if your incapacitated) Putting that information in a Safety deposit box at the bank and giving a trusted person the keys for an emergency is the simplest way. I personally prefer a dual layered approach that features both active intrusion countermeasures initially followed by denial of resource. should the first layer be circumvented :shadow1: ;)
Additionally If they can break into your house and get to your computer and remove it to futz with at their leisure, odds are a healthy chunk of your security is compromised.
I use a second browser for all my critical online transactions which I have set to be rather draconian in handling and deleting all history records. Even more importantly is I run it off an encrypted drive. Then again I am really paranoid. However even this isn't a good guarantee. If your house is broken into you should probably immediately go about changing all of your online passwords. while forums might not be important, god knows they are tech savvy criminals they will be pouring through your email to find new leads on ways to rip more stuff off.
Frequently there is a reciprocal relationship between breaches in physical and electronic security. One can easily be a prelude to another. If you notice you are the target of a fairly systematic series of online attacks, it can be a prelude to a physical security breach. They might be fishing for information on your routines, schedules and personal security procedures (or lack their of). So if you see lots of intrusions on the electronic side, shake up your physical security procedures, so that any information they get is somewhat degraded and lowers your exposure.
I'm looking at the average person and saying that you don't want to look up your password every single time, because if you do, no amount of physical security will help because that physical security will impede you from being able to use your reference readily. Therefore, you'll leave the password somewhere more easily accessible, and probably completely insecure. Thus your passwords need to be written in a way to remember them.
Obviously some people are better at remembering passwords than other.
A trick I use for that is I set a password I plan to eventually use online as my local system login for a few months. I have it written down (the only one I write down) and set my system to require a password to exit screensaver. After typing the password for several months, you better well know it. Then you tear up the sheet you wrote your password on and distribute it over several trashcans over several weeks so that anyone that dumpster dives can't reassemble it. Then I start using it online as a remembered password.
Since it was used only for your local system, if someone broke in and stole your password, they could have also stolen your system, and no amount of password will help you if you have a Windows system.
Another important item is to NOT use your browser's "Save Password" feature for secure sites (or unsecure sites where you use secure passwords). Always type in your password. You'll note that in Firefox, the passwords are readable within their manage passwords interface. A thief can also read them there.
--RC
Fire.
Jake
Only /boot is unencrypted, but if you really were really worried about a backdoor getting on /boot (either by a malicious insider or a remote exploit which manages to gain root access and mount /boot while operating) I guess you could put /boot on a write-protected memory stick and carry it with you.
It's a relatively minimal Linux install (but with KDE, since graphical remote access is needed too) which offers no services, has stack smashing and buffer overrun protecions compiled in, and a privilege policy generated with the "learning mode" of grsecurity.
Backups are TrueCrypt-based and naturally stored remotely.
The box is never used to run the code it's used to deploy.
Most other systems are way more lax. This one got a paranoid installation however, since remote access passwords had become concerningly many. Even now they're concerningly many, there's been talk of splitting the risk between two such boxes.
The grievously funny thing is, of course, that only a low percentage of customers can accept SSH or tunnel things through it. Mostly it's cleartext RDP, VNC or various SQL protocols (fortunately protected from random login attempts by IP filters). Telnet most fortunately has faded away into history.
Only /boot is unencrypted, but if you really were really worried about a backdoor getting on /boot (either by a malicious insider or a remote exploit which manages to gain root access and mount /boot while operating) I guess you could put /boot on a memory stick and carry it with you.
It's a relatively minimal Linux install (but with KDE, since graphical remote access is needed too) which offers no services, has stack smashing and buffer overrun protecions compiled in, and a set of privileges established with the "learning mode" of grsecurity.
Backups are TrueCrypt-based and naturally stored remotely.
The box is never used to run the code it's used to deploy.
Most other systems are way more lax. This one got a paranoid installation however, since remote access passwords had become concerningly many. There's been talk of splitting the load (and risk, by having only half of data on each) between two such boxes.
I'm looking at the average person and saying that you don't want to look up your password every single time, because if you do, no amount of physical security will help because that physical security will impede you from being able to use your reference readily. Therefore, you'll leave the password somewhere more easily accessible, and probably completely insecure. Thus your passwords need to be written in a way to remember them.
--RC[/QUOTE]
The physical security is why I suggested the safety deposit box, now if you want to keep passwords written down and scattered around your house, contact myself and biggles to arrange for autonomous smartguns and kill bots to secure your house.
or just don't do it, whatever is easiest ;)
And now to waiting what is sentence.
(if it would be calculated similarly to Copyright mafia... err industy it would be hundreds of years and millions)
[QUOTE=sinclair;165976]Be happy its -only- password nowadays, in few years its going to be a pass phrase for sure, and it should be like that already.[/QUOTE]Yep, ever increasing CPU power makes cracking hashed passwords faster all of the time... and this type of calculations should be very easy to multithread for as many cores as there's available.
And you wonder why I just adopt the "shoot them in the face" policy to those attempting to breach my security.
You can start from toes, then go to fingers... :shadow1: