decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Pure Gold | 248 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Pure Gold
Authored by: SilverWave on Tuesday, August 21 2012 @ 06:34 PM EDT
Sites:

No, SHA1 is not a secure hashing algorithm

Use SHA512crypt, Bcrypt or PBKDF2.

Use a salt.

---

Users:

Don't reuse passwords between sites.

If you want use some kind of pattern *DONT* but if you do... at least use
something 14 characters long.



---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | Parent | # ]

Why passwords have never been weaker—and crackers have never been stronger
Authored by: Anonymous on Tuesday, August 21 2012 @ 08:35 PM EDT
Yes you can "crack" a password quickly if the hash is known, is
produced via a quick insecure algorithm, and isn't salted. So ... beef up
security for hash tables, use secure algorithms, and apply a dose of salt.

Millions of individuals all struggling to think up longer and more unlikely
passwords and phrases isn't a good solution. Better security around hashing and
hash tables is more likely to have an impact.

[ Reply to This | Parent | # ]

Something to think about ...
Authored by: nsomos on Tuesday, August 21 2012 @ 09:04 PM EDT
For your consideration ..

https://www.grc.com/haystack.htm

Determines how large the search space would be for any given password.
Everything is done locally. The point is made that one of the most
important factors is how long the password is. Simply padding can
do wonders for making a password harder to crack.

There are also a number of password related links at bottom of that page.

[ Reply to This | Parent | # ]

Reminder: A Simple Approach to Complex Passwordseaker—and crackers have never been stronger
Authored by: Anonymous on Tuesday, August 21 2012 @ 09:43 PM EDT
Some time ago I posted to the effect that using the first letters of each word
of a passage you've memorized can produce an easy to remember but quite long
password. For example.

IPATTFOTUSOAATTRFWISONUGIWLAJFA

Those 31 letters come from the US pledge of allegiance; I used it because it's
"obvious."

Those of you who may have memorized parts of the Aeneid in school have a good
place to start. Or maybe you played Algernon Moncrieff in a school production
of The Importance of Being Earnest and remember some of the dialogue ...
whatever.

The point is that searching World, or European, or even English literature,
textbooks and speeches for passages of 30 words or more is more trouble than
it's worth for any but the three letter agencies.

Marketer

[ Reply to This | Parent | # ]

Scary stuff, but
Authored by: cjk fossman on Wednesday, August 22 2012 @ 01:23 AM EDT
As others have pointed out, this scenario assumes that the
criminal has gotten the user ids and passwords.

As far as I know, there are only two ways to accomplish this
feat: SQL injection and rooting the server.

For SQL injection, the two RDBMS's I know about provide a
simple and effective means of prevention. Any programmer
who fails to escape user input by these means should be
expelled from the guild and his or her head impaled on the
pike next to the city gates as an example to others.

Keeping the bad guys from getting root is more complex.
Even a sysadmin who follows the best practices *could*
become a victim. Even so, the best practices should be
sufficient unless you have a very determined criminal
knocking at the door.

And by the way, let's drop this pedant's war over "hackers"
vs. "crackers" and call them what they are: criminals.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )