Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Out of curiosity, I just want to know the full form of "S/KEY" authentication method.
What does 'S' stand for ? and why is it written like S/KEY ?
According to RFC1760 and the original paper, it would stand for "secret key". More specifically, S would stand for the initial secret used in the hash chain.
A sequence of one-time passwords is produced by applying the secure
hash function multiple times to the output of the preparatory step
(called S). That is, the first one-time password is produced by
passing S through the secure hash function a number of times (N)
specified by the user. The next one-time password is generated by
passing S though the secure hash function N-1 times.
I've always heard/been told that S/KEY just means Secure Key or Security Key. As for why it's written that way, I have no idea, but I would assume it's just short-hand to not have to type the whole thing.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
This is a theory based question as opposed to any code related question.
I'm trying to establish how data is encrypted and differences client side to server side.
Is the data encrypted when it is added to the database/server?
Or are we just relying on data to be secure due to HTTPS which surely does not apply when the data is transmitted from the form to the database? or does it?
What kind of encryption is mostly used these days?
The data is not encrypted in the client. When HTTPS is used all data is encrypted during transport over the Internet. When the server application receives the data is has already been decrypted. If you need to store the data the server app will need to perform that encryption.
By this question it is clear you do not understand security so you are not ready to create a system that needs security. The solution is to hire a security professional to help you seeding the security. Security is very difficult to get correct and your users rely on and expect a secure system, please provide that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a plain text and its cypher text. I know that the algorithm used was MD5. I want to break all cypher texts that are produced using the same algorithm.
Is there any way to do so?
Kerckhoffs's Principle applies here. Knowing the mathematics, and the interaction between the plaintext and ciphertext, will not let you break the MD5 hashing algorithm.
This is due to Shannon's principles of cryptography, outlined in 1945, "Confusion and Diffusion". In simple terms, this means that any even reasonably good encryption algorithm does not show a clear relationship between the cleartext and the ciphertext.
The short answer to your question is no, there is no way to break MD5 purely by knowing a cleartext and a ciphertext. There's no key, so you can't reverse engineer it like a simple XOR cipher.
However, **as MD5 is a very quick, processor-light algorithm, it has been (and is still) possible to simply bruteforce a vast array of cleartext strings, then compare your target ciphertext to the resulting **rainbow table.
This site can help you do this: MD5 Decryptor
I will mention, however, that it's generally rare that there is a use for this outside of computer misuse, which I will strongly caution you against.
I hope this was helpful.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to generate a file that contains a stored procedure query and I want to share it, but I need to protect it from reading. This query will be used by another person in his own database and server.
I want to give a SP to another person to use in a different environment but doesn't want them to be able to read the TSQL in the SP.
How can I do that?
You can use the WITH ENCRYPTION clause. However, it is known to be ineffective and easily broken, and there are third party tools available that will let your client break it.
If you want to do it anyway, a tutorial can be found here.
If you use WITH ENCRYPTION along with a thoughtfully constructed EULA, your client should not accidentally see the code, and if he purposefully goes to the trouble to crack your code encryption, you will have civil recourse (i.e. you can sue them).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
There is a password generator that generates passwords based on known rules (a minimum of 10 characters in length, at least 1 of each of uppercase, lowercase, and numeric characters).
No ability to see the source code for this generator. I am just able to generate passwords and automate this process.
How would you test if this generator provides unique passwords assuming each password meets rules specified?
Thanks,
Racoon.
It does not generate unique passwords - that much I can guarantee you.
If you run this password generator a hundred billion times, what are you expecting to be true of the output? Are you really expecting that every one of those hundred-billion passwords will be different?
If what you're instead trying to ask is whether the passwords will be reasonably unique, then you need to define what you mean by 'reasonably unique'.
It also depends on the nature of the rules you specify for generating these passwords. If you specify a maximum length for passwords, then you have by definition set an upper limit on how many unique passwords there even are. Even if you don't, the only way you're getting guaranteed-unique passwords is if said passwords are allowed to grow to lengths that will make them totally impractical to use.
I think my question was incorrect. Every password generator sooner or later provides a value that have been earlier. Better think of randomness than unuqueness.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm looking at the various bcrypt implementations across several languages and noticing the character limitation across most - specifically, the 72 character maximum that node-bcrypt, php's bcrypt, and py-bcrypt all exhibit.
What are the advantages and disadvantages if an application were to run user input through, say, a SHA-256 or SHA-512 checksum beforehand to enable longer inputs for bcrypt?
The CLI application found here is limited to 8-56 "characters" inclusive (it's C, so a character can be anything I suppose). Heaven knows why you would create limits for something that you feed into a password based key derivation function afterwards (which almost certainly will take unlimited input).
An additional secure hash with sufficient strength and output size will not do anything to degrade security.
Encode the result to hexadecimals before feeding it to a bcrypt library, which is almost certainly expecting a String (don't get struck by the "odd" 00h byte). You might as well use SHA-256, I don't think a few bits more or less will make a difference if you feed it into bcrypt afterwards. Otherwise you may be forced to use base64.
Finally, try not to get into this situation, performing non-standard cryptography is almost certainly a bad thing.