Tag Info

New answers tagged

1

See this question for details. Roughly speaking, when iterating a hash function in a space of size N, then, after an average of roughly sqrt(N) steps, you enter a cycle whose length is of size roughly sqrt(N). With a, say, 160-bit hash function (e.g. SHA-1), both sizes will be about 280, i.e. way too large for problems to actually occur.


3

Assuming that you're using per-user salts (i.e. a different salt for each user account), rainbow tables are already an impractical means of attacking the hashed passwords (rainbow tables are typically used where there is either no salt or a salt which is common to all accounts and preferably known to the attacker ahead of time). Where you're using a ...


3

First: Salts are not meant to be secret. So, I'm not sure what is accomplished by this approach. Second: if you have to brute-force the salt, then the attacker can too. What I'm assuming is that your approach depends on the attacker not knowing your custom encryption scheme, and this is a bad idea. The strength of encryption is that it is secure even if an ...


1

My best understanding of your question is: Given a hash, from a known hashing function, if I apply the hash to itself any number of times, shall I ever receive the same number again? In that case the answer is "Possibly in a very,very,very,very long time depending on exactly what algorithm you use and how you use it." A word about multi-hashing At ...


5

Extracted from HashCat Forums, this method works for me (requires Python): --Download pdf2john.py from the suite John the Ripper (OCLHashCat works with the same hash format as John the Ripper): wget https://github.com/magnumripper/JohnTheRipper/archive/bleeding-jumbo.zip unzip bleeding-jumbo.zip cp JohnTheRipper-bleeding-jumbo/run/pdf2john.py . ...


0

In your question you have identified a potential threat. If you think this threat is real and it would have a sufficiently negative impact on your operations if it were exploited, you should take additional measures as you suggest in your question. If you are saying the keys in this case are unique identifiers which you do not want exposed, you may need to ...


1

Yes, you should verify it. If an attacker can replace the installer file on the server with a malicious version, https (TLS) will not protect you because you're downloading from the correct site, but you're getting a malicious file. If the publisher has kept their private key truly private, even though the attacker has compromised the server, the attacker ...


0

Lets say you need to view the IPs over a 30-minute period to decide on abuse. Here is a scheme to keep the IPs no longer than one hour. Every 30 minutes, generate a memory-only random string, RS. For any time period, keep the current and previous RS: rs_c, rs_p. For every IP, compute the current hmac using the current random string: IP_c = HMAC(rs_c, IP) ...


6

You cannot, in full generality, infer the hash algorithm from the output. An output is just a sequence of bits, and hash functions that produce n-bit outputs can at least theoretically produce any sequence of n bits of output. However, some people can make quick inferences (perhaps too quick), by saying that among the "usual" hash functions, only one ...


3

From the RFC, note 2: Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does ...


1

They do, you can lookup Metamorphic code(http://en.wikipedia.org/wiki/Metamorphic_code) and Polymorphic code(http://en.wikipedia.org/wiki/Polymorphic_code). They are techniques to make malware harder to detect by changing the code each time it's executed. Most AV-products rely on hashes, the other way to detect malware is by using heuristic scanning where ...


1

File hashes are by far not the most helpful method of detecting malware (unlike a couple of decades ago). Today, malware recognition (and sometimes classification) is heavily based on real-time heuristical analysis of its operations. This analysis deals with lots of data, which mostly consists of the system calls performed by the application, and their ...


2

My answer assumes you are asking this for a production system, and that you aren't asking this because you are starting to learn to be an anti-virus researcher. Can you do it? Yes, as other answers have stated there are many databases which list hashes, or can ID a threat by a hash. but should that be your only line of defence? However, there is a ...


2

Do a quick search on google and you find a lot of databases. OWASP offers one with a pretty easy interface: OWASP File Hash Repository. Simply send a DNS query with the Hash in MD5 oder SHA-1 prepended to hash.sapao.net (see "Testing the system"). If you want to run a large number of queries, I suggest you make a copy of their freely available Amazon AWS ...


1

You can submit the hash to VirusTotal by selecting 'Search' and entering the hash. VirusTotal will return the status if it's seen the file before -- if it hasn't, you may be out of luck.


3

There is no known property of the first/last/middle/whatev 60 bits of a SHA-256 output that would make them more/less "randomish" than the last/whatev/middle/first 60 bits. In other words, you could take the first 60 bits, and that will be as fine as you can get. With such a random generation, you can indeed expect the first collisions to appear after one ...


0

In short, no. You would have to essentially run a program to create random inputs into the hash function, and store the output, hoping that it (the output) matched what your target hash. The point of hashing functions is that they are one-way, meaning that given a hash value, it is computationally infeasible to generate the specific input that would ...


5

No. Given some output x, any input m such that h(m) = x is called a preimage. Though there are a lot of possible preimage, finding any of them is unfeasible -- that is, if the hash function is indeed cryptographically strong. The three classical properties of cryptographic hash functions are: Resistance to preimages: given x, it is not feasible to find ...


2

You can build an MPI cluster, which is supported by John the Ripper. However note that even 18 core2duos will probably not be as fast as a 150 USD GPU.


0

While memory-limited algorithms are discussed in the altcoin community ("alternative" cryptographic coins based on ideas similar to bitcoins), they do not primarily solve the disparity between a "low-end" general purpose computer (e.g. the RasPi) and a high-end general purpose computer, but they are used to prevent special-purpose hardware that exceed ...


-1

Larry>>SHA1 does not use a key. Signing is done with 2048 bits RSA, SHA1 is just used for Message Digest. If data is less than 2048 bits you get equal strength in the signature without SHA, just pad the data with FF, the strength of the signature is in the key-length not in the Message Digest process. Using SHA1 alone as a signing method is not recommended. ...


0

Performing the card lookups against a hash rather than against an encrypted value is done for speed so it is for performance, rather than security, benefit. In terms of security and the limited number of values required to create an effective rainbow table against hashes, a salt should be used. A simple, relatively unique salt per card number would be the ...


2

You're encrypting your document with a polyalphabetic cipher (the best-known of which is the Vigenere cipher). Techniques for breaking these have been known since the mid-1800s. Yours is particularly vulnerable since the number of alphabets (64) is fixed, and the alphabets are simple rotations (as opposed to shuffles). If you really want to protect your ...


6

this is only brute-forceable if you know what to expect Stop right there. What you're describing is security through obscurity. You're betting that an attacker won't be able to know or guess your scheme. This is a really, really, really terrible assumption. It's an alluring one, but time and again it's been proven wrong. Any proper security scheme must ...


0

Use a cryptographically secure random number generator to generate a random sequence. There are many available, built into different platforms. Many frameworks and languages provide wrappers to access these such as the openssl_random_pseudo_bytes function in PHP. You could generate your own. The article above suggests: A cryptographically secure hash of ...


0

PRNG(seed)=a string of random numbers hash(salt+password)=hashed password The random number generator highlights the fundamental nature of computers. They are not random. Even the perceived randomness is not random, but close to random, though one might eventually pull out that old hat example of walking half distances towards a goal and never really ...


4

The simplest terms I can think of: A seed is a random value which generally has to be kept secret or the encryption is broken A salt is a random value that is generally not a secret, which is used to make some precomputed attacks harder I like to use those because the idea of keeping things secret or not is something meaningful to anyone.


1

Most random number generators just generate pseudorandom numbers. They create a series of numbers which appears random at first glance, but the numbers do follow an exact algorithm. To prevent them from generating the same series of numbers everytime they are used, they are initialized by seeding them with a start value. A good pseudorandom number generator ...


-1

The encryption seed is used to help generate a pseudo-random number. The seed is used to initiate the generation of a series of pseudo random numbers and increase the statistical randomness of the algorithm used. You can never really generate a truly random number via computation alone which allows some skewness on a probability curve showing the ...


5

Your friend is actually justified in his confusion, because there isn't a big difference. At a high level, each is used as input to modify the output of a scrambling function. Try emphasizing the difference between a hash function and a random number generator, and what they are typically used for. Also, be able to distinguish between a regular random ...


1

As you and schroeder said, a salt is used along with some message as input to some one-way function so that the unsalted message can't be deduced. That is usually done by means of cross-referencing the digest (output) with a rainbow table: if my password is god and stored by a service as md5(god), then an attacker would require virtually no computing power ...


27

Seed: Encryption is powered by random numbers, but how do you generate a truly random number? The current millisecond? The number of processor threads in use? You need a starting point. This is called a seed: it kicks off a random number. Salt: When you hash a string, it will always end up with the same hash. foo = acbd18db4cc2f85cedef654fccc4a4d8 ...


1

If you consider bank account numbers sensitive, then yes it is worth hashing them. When we talk about hashing we should always talk about salting the hash. In this case it would be computationally expensive for you to salt each hash separately, which is the approach you should alway start with. As you are trying to use this as a look up value based on the ...


3

Be wary of hashing things where people might determine characteristics of the input. One company used MD5 of taxi IDs for anonymizing, which was quickly reversed. Yes, you could try some home-baked hash modification that would make it less obvious than just a straight MD5, but that's security through obscurity. Solving almost any hashing function for every 8 ...


2

I know that people often suggest slow functions like - PBKDF2, Scrypt etc.. Listen to them. Use scrypt, bcrypt or PBKDF2. These functions are designed for hashing password. See How to securely hash passwords? for details. This is the recommended approach to hashing passwords. but is using HMACSHA256 safe too? It's fast => brute-force is cheaper => ...


2

The actual processes are not publicly known, however they do maintain an official Tech Blog which gives some insight to the internals of Dropbox. For instance, their post on Streaming File Synchronization (July 2014) provides a high-level overview of the "Dropbox File System" which dictates the handling of all user data in a highly efficient and reliable ...


1

There is another way to do this that has not be mentioned so far that seem to me to be more secure. I like to think that such a large corporation would not store our passwords in any of the ways mentioned by StackzofZtuff but you never know. My proposal is that when you attempt to signup, they find all other accounts with some identical piece of personally ...


1

B) is in fact the correct answer, at least for the kinds of attack found against MD5 and SHA1. Those hashes are vulnerable to a collision attack, which means an attacker can reasonably find two things that hash to the same value. If he gets the victim to sign one, he can then just use that same signature on the other. However, he can't necessarily find ...


0

This is still incredibly confusing. I'm running Chrome 40 and like you I've just spent far longer than I would have liked figuring out what's going on. The CSP 2 spec says this about hashing <script> elements: For example, the SHA-256 digest of alert('Hello, world.'); is ...


1

I don't think an authoritative answer to this can be given. It'd have to be someone who works with the relevant portions of the software, and odds are the exact algorithm is deliberately kept secret. However, we can offer more-or-less well-founded speculation. Besides storing the password more-or-less-unsecured as speculated by StackzOfZtuff there is ...


1

This is bad. They're either storing the password: * in unsalted form (which is bad), * in reversibly encrypted form, from which they can reproduce the plaintext (this is worse), * in unencrypted form (this is the worst). The prefered way to store passwords is in salted form. This is explicitly made to prevent identical plaintexts winding up as identical ...


0

Authentication is a complex mechanism with a lot of potential security failures that should be addressed. TLDR: use Open ID for authentication instead of implementing your own mechanism. Brute Force: you must take care of protecting against brute force in authentication (limit number of wrong attempts to login) and also protect against brute force of your ...



Top 50 recent answers are included