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 11 years ago.
Improve this question
I've seen some websites, particularly banking sites, that ask you to enter this (for example). Sometimes they ask for this to prove my identity over the phone.
The 2nd character of your password
The 5th character of your password
The 6th character of your password
To do this, a hashing algorithm won't work, would it? Surely something that should be as secure as a bank would have a way of storing the un-decryptable passwords?
Yes this can work without holding the plain text version of your password. Simply, when you originally set your password, the bank will hash the various combinations it will ever ask for, and store those hashes. This is very simple to implement, regardless of whether you have a fixed length password (i.e. a PIN number) or a variable length one. These hashes can be stored in a preset series of columns in the table related to the user, or as a simple 3 column table - ID (the primary key), UserId, Hash, and there is one row for each combination of n characters in your password.
I have doubts about the efficacy of this method over asking for the whole password though... maybe someone has a comment on that?
I would imagine they'd have some kind of private key system for decrypting (maybe even a private key per account, to improve security)...
It would be not too surprising, if (some) banks (or other big corporations) really stored plain-text passwords, or ROT13'd ones, or even double ROT13'd...
It's probably not a good item to discuss on an open forum, but what is to stop them from inserting your selected characters into a memory held, decrypted, copy of your memorable phrase or word at the appopriate locations, encrypting it and performing a binary comparison on the result?
They could just as easily keep a HASH of the single characters couldn't they?
You do NOT actually have to use a one-way HASH. You could just as easily use a two-way cypher, if you were certain that your key was secure. In this case they could easily keep the cypher on systems not accessible from the net.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 12 months ago.
Improve this question
There are some blog-articles in project I work, and,
I guess, its text field should be limited somehow
(probably it would be a JSON field one day)
There are no limitations in sense of domain -
user can write as much as he wants, but,
just to prevent DB harm by hack-attacks with uncommonly huge amounts of text, guess, some limit is needed.
As SO Q/A says:
PostgreSQL limit text field with 1GB Is there a maximum length when storing into PostgreSQL TEXT
http POST limits depend on browser (2GB - 4GB) https://serverfault.com/questions/151090/
By rumors, Nginx's default client_max_body_size is 1MB
So, how to deal with all of that?
Probably, there are some practice like:
"Just limit it with million chars in app-lvl and don't worry"?
This is an interesting question. If I understand correctly you are working on an application where the DB entry will essentially be a blog post (typically 500-1000 words based on most blogs I read).
You are storing the blog post as a text field in your database. You are quite reasonably worried about what happens with large blobs of data.
I fully advocate for you having a limit on the amount of data the user can enter. Without fully understanding the architecture of your system it's impossible to say what is the theoretical max size based on the technologies used.
However, it is better to look at this from a user perspective. What is the maximum reasonable amount of text for you to have to store, then let's add a bit more say 10% because let's face it users will do the unexpected. You can then add an error condition when someone tried to enter more data.
My reason for proposing this approach is a simple one, once you have defined a maximum post size you can use boundary value analysis (testing just either side of the limit) to prove that your product behaves correctly both just below and at the limit. This way you will know and can explain the product behaviour to the users etc.
If you choose to let the architecture define the limit then you will have undefined behaviour. You will need to analyze each component in turn to work out the maximum size they will accept and the behaviour they exhibit when that size is exceeded.
Typically (in my experience) developers don't put this effort in and let the users do the testing for them. This of course is generally worse because the user reports a strange error message and then the debugging is ultimately time consuming and expensive.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are moving a logging table from DB2 to Oracle, in here we log exceptions and warnings from many applications. With the move I want to accomplish 2 main things among others: less space consumption (to add more rows because tablespaces are kinda small) while not increasing the server processing usage too much (cpu usage increases our bill).
In DB2 we basically have a table that holds text strings.
In Oracle I am taking the approach of normalizing the tables for columns with duplicated data (event_type, machine, assemblies, versno). I have a procedure that receives multiple parameters and I query the reference tables to get the IDs.
This is the Oracle table description.
One of the feedback I have so far from a co-worker is that I will not necessary reduce table space since indexes take space and my solution might end up using more than what saving all string uses. We don't know if this is true, does anyone have more information on this?
I am taking the right approach?
Will this approach help me accomplish my 2 main goals?
Additional feedback is welcome and appreciated.
The approach of using surrogate keys (numerical ID) and dimension tables (containing the ID key and the description) is popular in both OLPT and data warehouse. IMO the use for logging is a bit strange.
The problem is, the the logging component should not have much assumption about the data to be logged - it is vital to be able to log the exeptional cases.
So in case that you can't map the host name to ID (it was misspelled or simple not configured), it would be not much helpfull to log unknownhost or to suppress the logging at all.
Concerned the storage you can indeed save a lot storing IDs istead of long strings, but (dependent on data) you may get similar effect using table compression.
I think the most important thing about logging is that it works all the time. It must be bullet-proof, because if the logger fails you lose the information you need to diagnose problems in your system. Even worse would be to fail business transactions because the logger abended.
There is a strong inverse relationship between the complexity of a logging implementation and its reliability. The more moving parts it has, the more things there are to go wrong. So, while normalization is a good thing for business data it introduces unwelcome risk. Also, look-ups increase the overhead of writing a log message and that is also undesirable.
" tablespaces are kinda small"
Increasing the chance of failure is not a good trade-off. Ask for more space.
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 7 years ago.
Improve this question
I'm am just now learning Ruby programming language on my own, and was wondering in what cases would it be more useful to use a hash instead of an array? It seems like a hash is simply an array where each element has a name rather than an index. Thanks.
Hashes are great as libraries where you want to store specific pieces of information for multiple things. Think of it as an excel table with the columns representing specific data (i.e. Name, Age, Address, etc), and each row represents a single person with specific information stored.
Lets say you want to access a specific information in this hash you built or generated. Well, their name has to be "Philip" and their Age has to be greater than 20.
my_hash.each do |person|
if person[:name] == "Philip" && person[:age] >= 20
puts person
end
end
Not particularly Ruby, but JSON (JavaScript Object Notation) uses a hash structure to store a ton of information. Also, when you consume API's, a lot of the data you receive will be in hash notation that you will then need to parse and take needed information from.
You're exactly right, while arrays hold an integer as the key, hashes can store any object as the key. because of this, arrays are more data efficient*, but hashes are more flexible. I'd recommend using whichever you are more comfortable with for now, unless you are very concerned with using as little data as possible.
I will release my GAE application in a few months on a closed beta state, so that just a few users can use it and I get some date and know where and how to improve it. My idea was that I use a key system to let them access the application.
What I want to do:
I want to generate a punch of keys and store them with Datastore. When a users comes to the application the first time he logs in with his Google account and has to enter a key to activate his account.
My question:
My previous software didn't require such license keys or similar so this is a new area for me. Do you think this is good way to realize a closed beta? My second idea was to generate a bunch of keys and validate them with a system like other popular software does it, but I think this is unnecessary and I wan't to avoid a that someone can make a key-gen. Just generating, storing, then checking the key if it exists in the Datastore, setting it to used and activating the account would be my suggestion.
How can I generate a lot of valid and easily add more (without duplicates) keys. I'm thankful for every experience and suggestion.
As a refinement to Ashley's suggestion, if you'd like to generate shorter and/or easier to type IDs, you can generate some random data and encode it using base32:
base64.b32encode(os.urandom(8)).strip('=')
Make it a bit more readable by inserting hyphens:
'-'.join(base64.b32encode(os.urandom(8)).strip('=')[5*x:5*(x+1)] for x in range(3))
This gives you codes like the following:
'C6ZVG-NJ6KA-CWE'
Then just store the result in your datastore and hand them out to users. I'd suggest storing the code without the hyphens, and stripping those characters before checking the database. If you want to get really fancy, base32's alphabet is chosen to avoid characters that look similar; you could substitute those characters before you do the check to account for typos.
8 bytes of random data gives you 2^64 possible invite codes; if you hand out, say, 2^16 (65,536) of them, an attacker will still have to try 2^48 (about 300 trillion) codes to find a valid one. You can make your codes shorter at the cost of reducing the search space, if you want.
I use UUID for generating random keys:
UUID.randomUUID().toString().replace("-", "");
From the docs: "The UUID is generated using a cryptographically strong pseudo random number generator".
Generate a long list of them in the datastore, and then when a user arrives at something like: yourapp.com/betainvite/blahblahkey you can simply check if the key is in the table, and if it's rsvp property is null (or already set to the date it was used, in which case you deny the invite).
You could store the key against your User too, so you can find out who used each one and when.
Also good idea to maintain an invited date on the keys, then as you use each one you can mark it as invited, so you don't double invite people.
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 7 years ago.
Improve this question
I'm implementing a small application in C, which I would like to sell as shareware for a reasonable price later on. It will start of with a 30-day trial, which I am already quite certain of how to implement it.
The problem I have, though, is that I am not quite sure how to implement the product key verification. What I have in mind is that the customer can sign up on my webpage (after trying the product for a while), pay for the product, and get a product key in the form of aaaaa-bbbbb-ccccc-ddddd-eeeee via e-mail (or maybe available via his profile on my website). No problem so far. He/She then drops the key in the appropriate key fields in my app and boom the app is registered.
From what I could gather so far, people either recommend AES or RSA for this. To be honest, I in another direction in college (not cryptography) and the one cryptography class I took was some time ago. But from what I remember, AES is a symmetric encryption algorithm, which would mean that I would only have one key for encryption and decryption, right? How could I then generate thousands of product keys and still validate them in my app (which by the way won't require internet access....so no checking back with a server)?
So I guess RSA would be the way to go? But doesn't RSA produce pretty long keys (at least longer than the required 25 characters from above)?
In another thread I read that some products won't even use encryption for the product key generation/verification, but instead just employ some checks like "add the 2. and the 17. character and that should total to x".
What's the fastest, easiest and most secure way to go here? :-) Code samples would be sugar!
Regards,
Sebastian
P.S.: Oh...and please don't tell me how my key can and will be cracked at some point.....I know about that, which is primarily why I don't want to spend a lot of time with this issue, but at the same time not make it too easy for the occasional cracker.
Symmetric algorithms are limited, in that any novice cracker with a disassembler can find your key (or the algorithm used to generate one) and make a "keygen".
For this reason, asymmetric cryptology is the way to go. The basic premise is something like this:
When the user purchases a license from you, you collect certain identifying details about the user and/or their environment (typically, this is just a full name; sometimes a company, too).
You make a 128-bit MD5 hash of this information.
Using a 128-bit Elliptic Curve crypto, encrypt this hash using the private key on the server.
The 128-bit cipher text can be represented to the user as a 25-character string consisting of letters and digits (plus separating dashes for readability). Notice that 26 letters + 10 digits = 36 discrete values, and that 36^25 > 2^128.
The user types this product key into your registration dialog. The client software converts it back to a 128-bit number (16 bytes), decrypts that using the public key of your EC crypto, and compares the result to an MD5 hash of the user's personal information, which must match what was used for registration.
This is just the basic idea, of course. For more details and source code, see Product Keys Based on Elliptic Curve Cryptography.
Life is simpler if you simply purchase a solution.
http://www.kagi.com/kagisolutions/index.php
Kagi allows you to collect payments and they help you manage the keys.
A guy has blogged about how he handled the question of registration numbers. One of his blog entries is Generating Unique Registration Numbers.
Yes, RSA and AES are two very different things:
RSA is public key cryptography, involving a public key and a private key, and is fairly slow. The primary use is to set up a secure exchange of a symmetric encryption session key.
AES is symmetric encryption, which is fast and secure.
Since your app does not communicate over public channels and the use of cryptography is limited to product activation/registration you'll want to go with a symmetric cipher. The benefits of public key ciphers is in key management, which you will be handling on your web site or through email.
Note that you do not have to distribute the same key for every customer. You could generate a hash of some of the registration info and XOR it with something else (a fixed session key, perhaps). Send that to the customer, and the program could generate the same hash and XOR will the key you sent to produce the original fixed key.
Dealing with cryptography is not something to be done lightly. As you mention, you expect this to be cracked. If you're doing your own this will almost certainly happen. You can still use your own implementation to "keep honest people honest," but realize that's as far as you'll get. If you need something stronger then you should purchase a solution after doing thorough research on the solutions.
You can check out this Code Project article. It describes an implementation of a a software key based on the MAC address of the machine where the software is executed. The method is not ideal, as the auteur himself admits, and it is a little bit different from what you are looking for, but maybe it can help you.