Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Lol why is dis 6kyu? look like 8 or 7 to me :P
Well that should be cleaner in the kata description which leave the door open for both aprouches.
But on the other hand that's pretty irrelevant for what this Kata is trying to show us.
Just cause using memo is an uncessary use of memory to calc a fibonacci number :P
It is unecessary to test all numbers to number to know if it is prime. Can skip all even numbers and reduce to the square root, saves looooooooads of tests :P
Description is very laking for beginners
Very simple :) totally a 8 kyu.
this assumes that there should be exacly 1 occurrence of each number always. the kata description doesn't say that just that it needs to have all elements from 0 to 9.
Lol, bravo! so simple so right!
Yet one thing remains, if both words are the same they aren't Anagrams (i think) the test cases fail there, but that's an extra if, lol.
Math yo, at first i was like wtf does he want with this, but then... dooh :P
I don't get it, fails at 6th test (invisible one). Does it not follow the kata input rules?
I'm with you all the way, but the point of this Kata was a javascript function, which means the salt is there heck even the final hash is there!
Knowing the password is not necessary to gain acess most times, considering that to be true has proven to be a huge security failure in the past.
But all you say is true when things are done server side, and real obscurity is in place, then and only then, all this makes sense :)
Also, I forgot to mention, lack of knowledge of an item is only the most basic security: security by obscurity. It certainly has it's place, but you should never rely on secrecy exclusively for securing something.
Think of security as an onion: the more layers, the more time it takes to crack, and the less likely your attacker will be successful. (i.e.: Hiding your treasure map is ok, but encrypting the map and then hiding it is much better!)
That's sort of the whole point of hashing passwords. You can get a copy of the hash (and even the salt), and still never learn the original password. (And, if the attacker does not have the ability to manipulate code server-side—which makes this moot anyway—they won't be able to assume the credentials of another person, because the server will require the password to still match.)
This is because the hashing function is a one-way hash. A one-way hash takes an input, and provides a completely different, nearly unique output (uniqueness mostly depends on input length and output length). Once you get the result, there should never be an algorithm to reverse the hash back into the input.
A cheap hashing function (such as MD5) is very fast, so you can brute-force the password in minutes (maybe seconds?) on modern hardware. But, with a good hashing algorithm, such as bcrypt or PBKDF2, with a high cost (or number of iterations), it can take days, weeks, or even years to brute force just one salted password†.
You can't pre-compute the passwords, using a rainbow table, because the salt is unique for each password. In a good security system, the salt is changed every time the password is changed, and is randomly generated. Salts don't have to be very long, because it's the simple fact that it changes the input that matters.
This whole system is sort of a technical variation of a messenger learning a password, then eating the paper it's written on. There's no way to get the original paper back—you must rely on the messenger (hash function) confirming that the password is the same. If you want the original password, you have to beat it out of the messenger (brute force), which could be quick for wimpy hashes with no salts, or may never happen if the hashing technique is exceptionally strong.
† This is why you never use obvious or guessable passwords. Given a list of common passwords, and an algorithm that can translate these into common alternate spellings (change case, swap
E
for3
, etc), even a perfectly hashed bad password could be cracked in minutes using good hardware.What's the point off all this when the relevant part's of your final hash are plain on the javascript? :P