I'm trying to set up some selenium tests to our staging server using Sauce Labs. It's behind a basic http auth, so theoretically I could set the selenium URL to http://user:password#www.stagesite.com. However, the password contains a "#", causing all sorts of problems as you can imagine. I tried escaping it with a backslash but that did nothing from what I can tell.
So,
is there an alternative way to do http authentication using selenium, i.e., not via the URL. Or,
is there a way to use URL-based auth but somehow tell the browser that the "#" is part of the password?
You just need to encode special characters like that before passing them as part of the URL, so # would need to be passed as %40, eg:
https://user:password%40www.example.com
(I typically use this - http://meyerweb.com/eric/tools/dencoder/ - for my en/decoding needs.)
Related
I have some sensitive information (my database username/password and cookie encryption key) in my config file for my Dancer application that I would rather not be shown as plain text in case someone does gain access to it. What's the best way to encrypt the file so it's not just text? Or is there a more secure approach that makes more sense than encryption (like restricting file permissions)?
Because you can't encrypt the config, as in the comment above says #ThisSuitIsBlackNot, but sometmes is good to hide passwords (e.g. hide the passowrds form some co-workers who doesn't knows perl - but has access to config files)
I'm using an combination of
security by obscurity
and fooling
In my config files are passwords in encrypted form, and looks like as instructions for configuration. If someone grabs/reads only the config file - get nothing usable.
Usually I'm using something like the next:
db.password: enter some safe password here such De4w.Quafy3yq
and in the code i exracting the "De4w.Quafy3yq" part and using rot13 or crypt etc... get the real passwd: "Qr4j.Dhnsl3ld". Or using the mh5 hash of a string as a password, or similar - simple algorithms.
It is simple, and effective against non-programmers - of course, isn't helps when someone knows perl and grabs the code too.
EDIT
Because seems (downvotes) than here are still some people who didn't understand what this mean, THIS ISN'T ANY REAL SECURITY. It is an nice (funny) method (of course unsecure - read again, it isn't mean any real security) how to hide the password form coworkers, who didn't knows perl. DON'T USE IT for any real password protection. OMG...
First time posting a question. I'm trying to call some SOAP webservices from inside a blackberry app using the ksoap2 library. I've successfully managed to get a response from the one service, which uses an HTTP url, but now that I'm trying to get response from a (different) HTTPS url, I've run up against a brick wall.
The response dump I'm getting has the following fault message:
"An error occurred while routing the message for element value : (country option I specified in my request). Keep-Alive and Close may not be set using this property. Parameter name: value."
The weird thing is that using Oxygen XML's SOAP tools with the XML request dump works just fine. Any ideas where to start looking? This has taken up a full day already.
Update:
Responding to your comment below - it turns out the double quoting is part of the SOAP spec. Some servers are more relaxed in their implementation, and will work without the quotes.
ksoap2 doesn't force the quotes onto your actions - you may want to patch your ksoap2 library to ensure the quotes are always there.
ymmv
Original:
I don't think this is a SOAP related problem, nor with BlackBerry.
I think the problem lies on the server side, since that error string is not a common error (just google it to see no hits on the whole internet other than this question).
Looks like this is a job for the network guy on the server side to tell you what he's seeing on his end.
Only other thing I can think of is to make the call using HTTP instead of HTTPS. You can then use some network sniffer to see what the difference between the messages is. Alternatively, install an SSL proxy with something like "Charles" and sniff the packets like that.
I wonder if it is possible to have an easy authentication method that is restful, fast and provides a litte security.
SSL is not an option, because I can't rely on a valid SSL Certificate on the server of clients. Also HMAC is not really possible because the body of the request should be signed, when used properly, but in my case that body could be a large file. Further should the authentication be possible with JavaScript/AJAX.
I thought about something really simple. What's the problem with that one:
HEADER: X-Authentication: timestamp:username:sha256(timestamp:password)
The server knows the users password and could check the hash, the timestamp is used to only allow request that took place e.g. 10 seconds before. The replay window would be extremly small, and there are no sessions on the serverside.
If the hash is cracked the attacker knows the password and has unlimited access.
Alternative would be to use
HEADER: X-Authentication: timestamp:username:HMAC(password, 'timestamp+request-method+verb')
What's the way to go? I'm not a security pro, maybe storing the session on the server would be better (but not RESTful)?
I built a random hash algorithm that does what you need, it's called jAuthenticate.
You can download it from: https://github.com/thomasoeser/jAuthenticate
You can see how it works here: http://furiousgryphon.com/jauthenticatedemo.html
The reason it's a strong algorithm (in my opinion) is that I'm using a random number to influence the hash but I'm sending an obfuscated number with the hash.
Each hash is single use only.
Have a look, it's free open source (MIT).
HTTP authentication is extensible so you can invent your own mechanism (obviously at your own risk!). See https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p7-auth-20 for details.
Don't bother inventing your own new X- header. Using the existing Authorization header with your scheme is a better option.
e.g.
Authorization: kruemel-auth timestamp:HMAC(password, 'timestamp+request-method+verb')
Ideally new schemes will be registered with IANA along with a specification. A registry is being setup to track auth schemes that have been developed. See http://tools.ietf.org/id/draft-ietf-httpbis-authscheme-registrations-03.html
I am using the request module in the Firefox Add-on SDK to access my Perl application. In the Firefox panel the user will enter his name and password which is relayed to my Perl CGI application.
Firstly, I would like to know if this is a safe approach.
Secondly, is there any chance of encrypting the data and then decrypting it again on the server side (written in Perl using the CGI module)?
Firstly, I would like to know if this is a safe approach.
As far as the client-side goes - depends on how you store this password. If you remember the password rather than requiring the user to enter it again each time then you should use Login Manager for that (which stores it encrypted if the user defined a master password). When using Add-on SDK you will need chrome authority for that:
var {Cc, Ci, components} = require("chrome");
You can then replace Components.classes in the examples by Cc, Components.interfaces by Ci and Components.Constructor by components.Constructor and these code snippets should work correctly in your extension.
Secondly, is there any chance of encrypting the data and then decrypting it again on the server side
If your goal is to protect against eavesdropping then you do not want to use symmetrical encryption - it uses the same key for encryption and decryption and the key used for encryption will be visible to anybody looking at the source code of your extension. So you want to use an asymmetric (public-key) encryption algorithm like RSA. However, using it "manually" in Firefox is currently very complicated and involves accessing the NSS library via js-ctypes (DOMCrypt extension does it this way). Not to mention that you would still have to think about replay attacks and such. The much simpler solution would be using an HTTPS connection to communicate with the server.
If I have an app that connects to Amazon's S3 service, is it worth my time to hide/obfuscate the connection strings and API keys? I'm guessing that most hackers won't care all that much, but it would be financially painful if someone found this information and was able to upload data to my account!
For instance, if I store a username/password (or Twitter/Facebook API key and secret), these may be easily found using "strings". A hacker could see the functionality, grab the secrets and use them for nefarious purposes. I've seen people suggest using a simple Rot13, or storing the strings backwards or something like that in the app binary. Are these useful?
Has anyone done this or have any ideas/patterns/code to share?
-dan
You can hide your secrets in a webserver you have full control over, and then having this server relay the query to Amazon. You can then use whatever encryption/validation method you like, since you are not relying on what is supported by Amazon.
Once you have validated that the request is from your own application, you then rewrite the query including your secrets and then forward this to Amazon. The result from Amazon could then be relayed directly back to the application.
In php this could for instance be done using something similar to this snippet (not showing your url rewrite):
$fp = fopen($amazon_url,'r',false);
fpassthru($fp);
fclose($fp);
You dont really need to hide them...what you should do is have an extra key such as a secret, that one IS hidden and is only present in the signature of the call (which can be an MD5 hash or sha (or whatever)) without that secret key people wont be able to just make calls since the signatures created by the server and the offender wont match since they dont know the secret key used...
I'm guessing that most hackers won't
care all that much
It just takes one who's bored enough.
Has anyone done this or have any
ideas/patterns/code to share?
This is what SSL is for. You can encrypt all your transmissions or just the login process (which would return a session id that can be used for subsequent requests during the session).