A salt is an IV for a hash. Client or server side.
I agree, its not secure on the client side. Considering this is a client-side solution to improve the strength of what is being "typed" into the password box, what happens on the server is irrelevant.
What matters is whether this solution provides a "better" password in that password box. In the most common scenario, Joe Sixpack will be using this program to put the hash of his fave mp3 into the password box, with the same realistic strength of "password69". So, its not secure on the client side, and it doesnt really provide better passwords in the password box. Seems pretty useless to me.
I agree that a better file should be used, The file needs to be unique and repeatably recoverable - might even rule out iTunes - if they change their DRM, or put a different tracking cookie in the file then you'd be locked out. So you'd have to start backing up your special file, and doing work to use this system.
Basically anything that involves a extra work for the client, or making it locked to one machine, means you may as well use a client cert - a solution that already exists in many forms, such as Cardspace.
My main point was that if you are dropping a few hundred developer hours of time into writing and maintaining a file system driver, the $200 is insignificant.
Additionally I'm pretty certain you could drop the CA-Cert root in your trusted store and it would all work fine.
Playing devils advocate, are you sure the patents on mp3 compression can't be read broadly enough that the frequency decomposition can cover whatever the hell vorbis uses (DCT?)
Correct, you've described how salting a hash is _used server side to give limited protection to password databases_.
Heres why you'd also want to do something on the client-side:
On the surface the hash of the key file appears to be more secure than the typical crap passwords.
However we can start cutting those 128bits down pretty quick, just like we cut the password keyspace with a dictionary attack. A reasonable dictionary to try would be the 1000 most popular mp3 files' hashes from edonkey. It'd even be worth trying the user's last.fm most-played list first.
I'd suggest the file approach is in fact weaker than a moderate password. (TBH, we should be pushing openid with cardspace/equiv).
This is why I mentioned salting the hash client side - it means everyone using Brittany Spears "Let Me Blow You" as their key file will have a different password, which is obviously desirable. Fixes the keyspace issue, but obviously makes the whole file selection rather redundant:P
Everything is still happening correctly at the server end, of course (Assuming Amazon aren't being complete assclowns).
*shrug* I read an article on it a few weeks back, had a look and couldnt find it again.
Still, it only takes a tiny amount of evidence your hidden partition exists for people to find out about it. Temp files refering to the X drive? Prefetch data? Non-zeroed swap? Shit that the logical disk manager leaves lying around?
And thats assuming the people asking for the hidden partiion are the "good" guys. It'd be a real clusterfuck if the "bad" guys decided that you might have a hidden partition that you don't. Rubber hose cryptanalysis that can only be stopped by divulging a password you don't have:P
Haha, so are you seriously suggesting that this system as implemented is going to be:
a) Generate a digest client-side by using a variety of things, such as hashing an mp3 file combined with something else (where from?)
or
b) Upload a 3 meg mp3 file, which the server can do the usual crap on like it would a password.
The year 2599 called. They want their bandwidth back.
The issue is not in server side storage. The issue is in what I choose to provide for authentication. If what I am providing is the hash of a file, then its easily reproducible. If *I* am munging the hash in some manner then *I* need the reproducible data with which the hash is munged on every box I use.
Couldnt login! Was trying to login to the wrong username (who shared my name), and the guys secret question was "lager?". Of course the answer was "yes".:/
That probably makes me guilty of all kinds of nasty shit by accident:P
And then someone with actual skill, rather than a basement geek that thinks truecrypt is cool, is going to pull the smart data off the hard disk, examine the access patterns, determine that there has been enough random access to the "blank" area at the end of your partition, call it as probable cause and demand the real key.
My advice is to not use software for big boys if you don't know what you are doing.
Because the enormous machine that has built up Britany Spears, and sunk ridiculous amounts of cash into her publicity, rehab, music, lyrics, etc. The majority of modern "music" is industrialised as fuck, and the performers are a bunch of barbie dolls that present the RIAA's product.
So I disagree. Britany is overpaid.
Of course there are real artists, struggling to get paid, that probably deserve money. I'm sure the majority of music produced these days is entirely due to the producers effort, and finding a face to stick in front of it is just part of the production process.
Under MSSQL all queries have gone via the execution plan cache since version 6 or 7.
For data processing, go for it. For CRUD, using sproc cripples your ability to use tools like Diamond Binding, and reduces performance.
You should be permissioning tables anyway, in addition to permissioning sprocs.
Blanket design guidelines only help you keep noobs under control - theres nothing worse (but its funny) then getting paid contractor rates to follow some weird guidelines that someone had come up with. Worst I had was some stupid ass code formatting rule that didn't play nice with Visual Studios auto-formatting. I'd spend a literal 20% of my time tab+spacing out code;)
Yeah I mentioned before, crap.Net devs almost universally have this idea that the data-access-for-noobs in the IDE is crap (mostly correct), that its not good enough for their "enterprise" app (probably incorrect), and the decent tools you can buy are "not good enough" (incorrect), and that they can do a better job with a code-generator (laughably wrong and leads to the epic fail we see here).
My favourite was the place that did all data access via a web service "for security", but still hit the SQL server box directly for some third party graphing crap. They just didnt understand that any attacker probably wouldn't follow the "All attacks on db server plz go thru the webservice" sign:)
Slashdot Mirror
90000 is a far cry from such popular groups as:
"If one million people join I will name my son Batman"
"If ninety thousand people join I will shave the slashdot logo into my pubes"
"Forty million people for anti furry discrimination"
In this modern age, having less than a hundred thousand indicates that nobody really cares.
-1 Suggestion Of Existance of IP ;)
TF2.
Try the free (next) weekend.
A salt is an IV for a hash. Client or server side.
I agree, its not secure on the client side. Considering this is a client-side solution to improve the strength of what is being "typed" into the password box, what happens on the server is irrelevant.
What matters is whether this solution provides a "better" password in that password box. In the most common scenario, Joe Sixpack will be using this program to put the hash of his fave mp3 into the password box, with the same realistic strength of "password69". So, its not secure on the client side, and it doesnt really provide better passwords in the password box. Seems pretty useless to me.
I agree that a better file should be used, The file needs to be unique and repeatably recoverable - might even rule out iTunes - if they change their DRM, or put a different tracking cookie in the file then you'd be locked out. So you'd have to start backing up your special file, and doing work to use this system.
Basically anything that involves a extra work for the client, or making it locked to one machine, means you may as well use a client cert - a solution that already exists in many forms, such as Cardspace.
My main point was that if you are dropping a few hundred developer hours of time into writing and maintaining a file system driver, the $200 is insignificant.
Additionally I'm pretty certain you could drop the CA-Cert root in your trusted store and it would all work fine.
I wouldve thought anywhere. This is South Australia.
I'd expect to pay at least that for someone that can develop drivers without introducing horrible bugs :P
Playing devils advocate, are you sure the patents on mp3 compression can't be read broadly enough that the frequency decomposition can cover whatever the hell vorbis uses (DCT?)
Its certainly a similar idea.
Errr...
It comes with flash and lets you play all the 360 games, and download games from arcade.
The only thing it doesnt do is backwards-compatibility, or have the space for downloading game demos and full length movies.
Troll more?
I browse normally with:
+1 to short comment, AC, Troll, Flamebait
Makes /. a much more interesting place.
You install andLinux.
At least $200! Thats almost two developer hours of money!
Pretty certain you can chuck whatever cert you want in the trusted root store / disable this behaviour.
The handy guide why to not get drunk with those people:
Ancient Egyptians: Too dead.
Americans: Beer too crap.
Greeks: Too likely to bugger you in the arse while you are passed out.
Correct, you've described how salting a hash is _used server side to give limited protection to password databases_.
Heres why you'd also want to do something on the client-side:
On the surface the hash of the key file appears to be more secure than the typical crap passwords.
However we can start cutting those 128bits down pretty quick, just like we cut the password keyspace with a dictionary attack. A reasonable dictionary to try would be the 1000 most popular mp3 files' hashes from edonkey. It'd even be worth trying the user's last.fm most-played list first.
I'd suggest the file approach is in fact weaker than a moderate password. (TBH, we should be pushing openid with cardspace/equiv).
This is why I mentioned salting the hash client side - it means everyone using Brittany Spears "Let Me Blow You" as their key file will have a different password, which is obviously desirable. Fixes the keyspace issue, but obviously makes the whole file selection rather redundant :P
Everything is still happening correctly at the server end, of course (Assuming Amazon aren't being complete assclowns).
Entirely possible. Now if only I wasn't too lazy to go thru your posting history to find a reference to you eating _anything_ :D
PS: Anything I post drunk counts double, as beer makes me smarter.
*shrug* I read an article on it a few weeks back, had a look and couldnt find it again.
Still, it only takes a tiny amount of evidence your hidden partition exists for people to find out about it. Temp files refering to the X drive? Prefetch data? Non-zeroed swap? Shit that the logical disk manager leaves lying around?
And thats assuming the people asking for the hidden partiion are the "good" guys. It'd be a real clusterfuck if the "bad" guys decided that you might have a hidden partition that you don't. Rubber hose cryptanalysis that can only be stopped by divulging a password you don't have :P
Haha, so are you seriously suggesting that this system as implemented is going to be:
a) Generate a digest client-side by using a variety of things, such as hashing an mp3 file combined with something else (where from?)
or
b) Upload a 3 meg mp3 file, which the server can do the usual crap on like it would a password.
The year 2599 called. They want their bandwidth back.
The issue is not in server side storage. The issue is in what I choose to provide for authentication. If what I am providing is the hash of a file, then its easily reproducible. If *I* am munging the hash in some manner then *I* need the reproducible data with which the hash is munged on every box I use.
How the server stores this crap is immaterial.
Couldnt login! Was trying to login to the wrong username (who shared my name), and the guys secret question was "lager?". Of course the answer was "yes". :/
That probably makes me guilty of all kinds of nasty shit by accident :P
Were they not doing it all for you until you assclowns decided to have a revolution and elect your own leaders?
Good going there... :P
And then someone with actual skill, rather than a basement geek that thinks truecrypt is cool, is going to pull the smart data off the hard disk, examine the access patterns, determine that there has been enough random access to the "blank" area at the end of your partition, call it as probable cause and demand the real key.
My advice is to not use software for big boys if you don't know what you are doing.
CONDOME.
Two cocks enter, one cock leaves.
Fat Tony has 6 votes of around .45 calibre that would like you mod me up.
Because the enormous machine that has built up Britany Spears, and sunk ridiculous amounts of cash into her publicity, rehab, music, lyrics, etc. The majority of modern "music" is industrialised as fuck, and the performers are a bunch of barbie dolls that present the RIAA's product.
So I disagree. Britany is overpaid.
Of course there are real artists, struggling to get paid, that probably deserve money. I'm sure the majority of music produced these days is entirely due to the producers effort, and finding a face to stick in front of it is just part of the production process.
MySQL with the X storage engine doesn't suffer from Y!
This makes MySQL the fastest, most available, most featured, most reliable and honest to god linearly scalable database ever invented!
Under MSSQL all queries have gone via the execution plan cache since version 6 or 7.
For data processing, go for it. For CRUD, using sproc cripples your ability to use tools like Diamond Binding, and reduces performance.
You should be permissioning tables anyway, in addition to permissioning sprocs.
Blanket design guidelines only help you keep noobs under control - theres nothing worse (but its funny) then getting paid contractor rates to follow some weird guidelines that someone had come up with. Worst I had was some stupid ass code formatting rule that didn't play nice with Visual Studios auto-formatting. I'd spend a literal 20% of my time tab+spacing out code ;)
Yeah I mentioned before, crap .Net devs almost universally have this idea that the data-access-for-noobs in the IDE is crap (mostly correct), that its not good enough for their "enterprise" app (probably incorrect), and the decent tools you can buy are "not good enough" (incorrect), and that they can do a better job with a code-generator (laughably wrong and leads to the epic fail we see here).
My favourite was the place that did all data access via a web service "for security", but still hit the SQL server box directly for some third party graphing crap. They just didnt understand that any attacker probably wouldn't follow the "All attacks on db server plz go thru the webservice" sign :)