I am using progress 4gl and progress database.
I need a one time password procedure for security purposes.
Do you have any idea.
I need two options. how can I generate random password and how is the process method ?
My progress version is 10.2b on windows platform.
My project is producing financial trasaction. Client and server side according to a specific algorithm (for example, 1 3 minutes) should produce the password. The generated passwords should continue with the same client process.
hikmet bey soruyu algılayamadım.nasıl yapacağınıza dair kod yardımı mı istiyorsunuz yoksa mantığı nasıl kurarım mı diyorsunuz.
Related
I recorded my jmeter script on server x and make it dynamic after that run that same script on server y - it fetch all data by post processor and did not give any error but data is not added on fronted . how can I solve it any reason behind it? (website is same just change the server for testing)
expected-Data should add on fronted like create lead on server y (successfully create on server x)
actual -data not added on server y
Most probably you need to correlate your script as it is not doing what it is supposed to be doing.
You can run your test with 1 virtual user and 1 iteration configured in the Thread Group and inspect request and response details using View Results Tree listener
My expectation is that you either not getting logged in (you have added HTTP Cookie Manager to your Test Plan, haven't you?) or fail to provide valid dynamic parameters. Modern web applications widely use dynamic parameters for example for client side state tracking or for CSRF protection
You can easily detect dynamic parameters by recording the same scenario one more time and compare the generated scripts. All the values which differ need to be correlated, to wit extracted from the previous response using a suitable Post-Processor and stored into a JMeter Variable. Once done you will need to replace recorded hard-coded value with the aforementioned JMeter Variable.
Check out How to Handle Correlation in JMeter article for comprehensive information with examples.
I am using Oracle apex 5,oracle database 12c
I have successfully configured oracle apex 5 with oracle DB 12c.
I have created authentication scheme using database table,that Authentication scheme worked successfully.
But my requirement is - Each user has to be connect to its own schema
(eg.user1 = HR; user2 = SCOTT)
with in same application.
Shortly, application must run on multiple schemas at run time.
But I am not able to get that,I have tried below stuff -
current parsing schema is 'SCOTT' try to change it using -
apex_application.g_flow_owner := 'HR'; --Failed
ALTER SESSION SET CURRENT_SCHEMA = 'HR'; --Failed
I don't understand what to do,Please some body help me for solving it.
I think you are on the right track, the apex_application.g_flow_owner := 'HR'; command should do the trick but you have to place it in shared components > security > security attributes> database session > Initialization PL/SQL Code
Edit: First of all having a schema for each user that logs into the application i do not think is the best approach. Just think that every modification has to be done to all the schemas. I suggest you take a look at Virtual Private Database (VPD) it can help you to control data access.
But if you still want to try changing the schema i think you can do it like this. Create two processes for each page in your application; one at On Load Before Header and one at On Submit. This process should contain something like this:
BEGIN
if :APP_USER='SCOTT' THEN
apex_application.g_flow_owner := 'SCOTT';
ELSE
apex_application.g_flow_owner := 'HR';
END IF
END;
Like this when Scott loads a page the schema is changed to SCOTT and he sees data from his schema. When HR loads a page the schema is changed to HR and he sees his data. Same thing when they submit a page; the schema first changes and then you do the other operations.
This second idea is not bullet proof and that's why i advise you to rethink what you want to do.
Edit2: In component view simply click on the plus sign on "Processes" to add a process and in the wizard select "On Submit - Before Computations and Validations" for the Point option.
I noticed that SQL Server Profiler includes an event when I use a deprecated feature:
Occurs when you use a feature that will be removed from future version of SQL Server, but will not be removed from the next major release of SQL Server. For greatest longevity of your applications, you should avoid using features that cause the Deprecation Announcement event class or hte Deprecation Final Support event class.
I turned it on and just before any Login event is recorded, I get:
Deprecated encryption algorithm rc4 will be removed in a future version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it. Use stronger algorithms instead.
But I'm not using RC4! I'm not even using AES. I'm using nothing. I'm just connecting to SQL Server.
Or am i?
Bonus Chatter
SQL Server, Deprecated Features Object
Deprecated encryption algorithm
Deprecated encryption algorithm rc4 will be removed in the next version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it. The RC4 algorithm is weak and is only supported for backward compatibility. New material can only be encrypted using RC4 or RC4_128 when the database is in compatibility level 90 or 100. (Not recommended.) Use a newer algorithm such as one of the AES algorithms instead. In SQL Server 2012 material encrypted using RC4 or RC4_128 can be unencrypted in any compatibility level.
Am I even doing anything wrong?
I'm simply opening a connect to SQL Server:
String connectionString =
"Provider=SQLOLEDB;Network Library=DBMSSOCN;Data Source=helium;
User ID=Contoso;Password=correctbatteryhorsestaple"
var conn = new ADOConnection();
conn.ConnectionString = connectionString;
conn.Open()
Even though the description of the event says:
occurs when you use a feature that...
Is it possible it is generated when I'm not using a feature? Is it possible this warning:
occurs when anyone logs in regardless of they are using RC4
and is actually just an announcement? Another application, an ASP.net MVC ADO-EF (a completely different connection technology) gets the same error.
The documentation of other deprecation warnings give when you would see them:
Occurs once per compilation.
Occurs once per query.
Occurs once per use in a DDL statement.
Event occurs once per database start and once per collation use.
Occurs once per use.
Whereas the documentation for this warning doesn't mention when you would see it.
Avoid using this feature in new development work, and plan to modify applications that currently use it.
How do I avoid RC4 in future work, when I can't figure out where I'm using it now?
Profile your 2008 R2 server. Do you get it?
☒ Yes
☐ No
Are SQL Server authentication passwords stored using RC4?
No. SQL Server passwords are not stored using reversible encryption. The passwords are salted and hashed using SHA-1:
hashBytes = 0x0100 + fourByteSalt + SHA1(utf16EncodedPassword+fourByteSalt)
In SQL Server 2012, they switched to SHA2 over SHA-1.
This happens on all my 2008 R2 Servers as well, it seems to happen any time that a connection is made using a SQL login, I can't seem to find any documentation on why this would be the case, I can only presume that internally SQL Server is using RC4 somewhere in the login process, so it's nothing that you are doing in your code.
There aren't any options that I know of to change this behaviour and it doesn't seem to cause any issues so I wouldn't worry about it.
I haven't seen this behavior, however.... when I call a procedure named: verifyPassword 'secret' (for example) the string secret gets commented out by the profiler. Because the string 'Password' triggers some 'pssstttt don't reveal this one' algorithm.
My fair guess that this is also the case when warning for deprecated functions.
I'm building a system that has a Java Swing front end accessed a postgres database. Prior to discovering Jasypt this week, I had originally planned to use Postgres' own encryption mechanism. It worked fine, but I also now wanted the passwords over the network to be encrypted, hence why I turned to Jasypt.
Problem is, I need a fixed password to be entered into my Postgres stored function. I.e. If the input password is 'aaa' then any other inputed password into the Postgres stored function (other than 'aaa') will not match.
Is there a way to get these two encryption mechanisms to work in tandem together or do I have to dump Postgres'?
My user table:
CREATE TABLE "user"
(
id serial NOT NULL,
cryptpwd text NOT NULL,
md5pwd text NOT NULL,
...
)
Encrypting password:
cryptedPassword = crypt(passwordIn, gen_salt('md5'));
md5Password = md5(passwordIn);
INSERT INTO "user"(username, cryptpwd, md5pwd, ...)
VALUES (usernameIn, cryptedPassword, md5Password, ...);
Decrypting password:
select ..... from "user" .... where username = usernameIn and cryptpwd = crypt(passwordIn, cryptpwd);
If I cannot get the two of them to work together then I would have to dump Postgres' mechanism as I need to have encryption over the network.
Also, with regards to the database connection string and database username and password (not using any framework ... plain old jdbc connection hopefully with SSL - yet to implement), I don't think I'll be able to use Jasypt because I'd need to decrypt it at database level. Would SSL alone be sufficient for this case?
Thanks.
I think SSL alone, on every piece of the path, would be sufficient. In LedgerSMB (although we are Perl-based) we do something different and rely on SSL protected links between servers and between servers and clients. There are a few things to think about with your approach though.
We actually pass the db username and password to the middleware from the client in re-usable format (plain text) over an SSL connection, and then use another SSL connection to log into PostgreSQL to authenticate this way. This works fine, but the problem areas we face are somewhat similar to the problem areas you will. These include:
Logging. Is it possible passwords will get accidently logged? This is a concern with LedgerSMB and we take what steps we can but a badly configured server or a tampered-with program could log usernames and passwords. In our case this comes primarily on the middleware level, but in your case, query logging could do this too, right?
Is it possible credentials can be re-used unintentionally? We prevent this in a couple of ways, but it is worth considering.
On the whole, we trust SSL. There isn't much to be gained from adding additional encryption beyond that, and key management adds a lot of complexity that is not worth the marginal gains IMO.
I'm making a site for a writers management company. They get tons of script submissions every day from prospective and often unsolicited writers. The new site will allow a prospective writer to submit a short logline / sample of his or her idea. This idea gets sent to an email account at the management group. If the management group likes what they see, they want to be able to approve that submission from within the email and have a unique link dispatched to the submitter to upload their full script. This link would either only work once, or only for a certain amount of time so that only the intended recipient could use it.
So, can anyone point me in the direction of some sort of (I'm assumine PHP + mySQL) CMS or framework that could accomplish this? I've searched a lot, but I can't seem to figure out the right way to phrase this query to a search engine.
I have moderate programming experience, but not much with PHP outside of some simple Wordpress hacks.
Thanks!
I will just give you general guidelines on a simple way to construct such a system.
I assume that the Writer is somehow Registered into the system, and his/her profile contains a valid mail address.
So, when he submits the sample, you would create an entry on the "Sample" table. Then you would mail a Manager with the sample and a link. This link would point to a script giving the database "id" of the sample as a parameter (this script should verify that the manager is logged on -- if not, show the login screen and after successful login redirect him back).
This script would then be aware of the Manager's intention to allow the Writer to submit his work. Now the fun begins.
There are many possibilities:
You can create an entry in an appropriate "SubmitAuthorizations" DB table containing the id of the Writer and the date this authorization was given (ie, the date when the row was added to your DB). Then you simply send a mail to the Writer with a link like "upload.php?id=42", where the id is the authorization id. This script would check if the logged user is the correct Writer, and if he is within the allowed timeframe (by comparing the stored "authorization date" and the current date).
The next is the one I prefer: without a special table just for handling something trivial (let's say you will never want to "edit" an authorization, nor "cancel" it, but it may still "expire"). You simply simply give the Writer a link with 2 parameters: the date the authorization was given and an authorization key, like: "upload.php?authDate=20091030&key=87a62d726ef7..."
Let me explain how it works.
The script would first verify if the Writer is logged on (if not, show the login page with a redirection after successful login).
So, now it's time to validate the request: that is, check if this is not a "forged" link. How to do this? It's just a "smart" way of construction this authorization key.
You can do something like:
key = hash(concat(userId, ";", authDate, ";", seed));
Well, here hash() is what we call a "one-way function", like MD5, SHA1, etc. Then concat() is simply a string concatenation function. Finally seed is something like a "master password", completely random and that will not change (for if you change it all the issued links would stop working) just to increase security -- let's say a hacker correctly guesses you are using MD5 (which is easy) and the he tries to hack your system by hashing some combinations of the username and the date.
Also, for a request to be valid, it must be in the correct time frame.
So, if both the key is valid, and the date is within the time frame, you are able to accept an upload.
Some points to note:
This is a very simple system, but might be exactly what you need.
You should avoid MD5 for the hashing function, take something like SHA1 instead.
For the link sent to the Writer, you could "obfuscate" the parameter names, ie, call them "k" for the "key" and "d" for the "authDate".
For the date, you could chose another format, more "cryptic", like the unix epoch.
Finally, you can encode the parameters with something like "base64" (or simply apply some character replacing function like rot13 for instance, but that take digits into account aswell) just in order to make them more difficult to guessing
Just for completeness, in the validation script you can also check if the Writer has already sent a file on the time frame, thus making it impossible to him to send many files within the time frame.
I have recently implemented something like this twice on the company I work for, for two completely different uses. Once you get the idea, it is extremelly simple to implement it -- maybe less than 10 lines of code for the whole key-generation and validation process.
On one of them, the agent equivalent to your Writer had no account into the system (actually it would be his first contact with the system) -- there was only his "profile" on the system, managed by someone else. In this case, you would have to include the "Writer"'s id on the parameters to the "Upload" script aswell.
I hope this helps, and that it was clear enough. If I find the time, I will blog about it with an working example on some language.