It's my first time to here, so please forgive me at first time if I make mistake. I am new to RSA(Cryptography), My requirement is, accessing private key from eToken for decryption and store decrypted data in a file.
I want to ask here that where to find private key & how to access it via jsp page?
I am using Spring 3 and RSA.
Please share resource if any available.
Thanks
Is the "eToken" the product described here? If so, it's basically a smartcard, which means you can't extract the private key. The way you'd use it is to send the encrypted data to the token and have it decrypt for you.
You said you're using JSP. Are you trying to utilize an eToken plugged into your server, or into the client's PC? A JSP page on your server can't talk to devices plugged into the client's PC; you'd need an application running on the client (maybe a browser plugin) to do it on your behalf.
If it were possible for a website to extract the private key from a user's eToken, the eToken would be worthless as a security product.
Related
I'm trying to solve the following problem:
The user has a public-private keypair. The public key is known, while the private key is kept secret by the user.
The webserver has data that was encrypted using the user's public key.
I want the user to be able to decrypt the webserver data using their private key (using a browser extension like MetaMask that has their private key stored), and then display that data to the user in a web page, while also PREVENTING the web page from being able to store that data.
Any suggestions on how this might be done?
Update; you can indeed do this with an iframe. Iframes are surprisingly secure actually. The browser effectively partitions the iframe from its parent, and vice-versa, even though to the user they look like they're the same page to the user. You can inject private information into a protected iframe on a webpage without giving that webpage access to the data. This is the method Stripe uses to embed credit-card entry fields directly into websites.
It seems to me that if my private and public key are compromised (which i use to sign and verify JWTs), that anyone can independently generate JWT tokens for themselves to use on my API?
Whereas on the other hand if I generated my own tokens myself, and stored a look-up table of 'one-way-hashed user id' => 'token', then if someone broke into my system, they would not be able to generate tokens to use on my API, and they would also not be able to use the tokens (because they would not know which token belonged to which user)
If someone breaks into your system and it is still secure, then you made a secure system; nothing to worry about.
with JWT, it appears to me that if someone breaks in, I do have something to worry about.
It seems to me that if my private and public key are compromised (which i use to sign and verify JWTs), that anyone can independently generate JWT tokens for themselves to use on my API?
Yes, that's correct.
Public keys are intended to be public and can be distributed.
On the other hand, private keys are supposed to be private and must be kept secure in your server. Anyone who has access to the private keys should be capable to issue tokens.
Disclosing your private key is a huge security breach.
It seems to me that if my private and public key are compromised (which i use to sign and verify JWTs), that anyone can independently generate JWT tokens for themselves to use on my API?
As also pointed out that you need to keep your Private Key Secure , the best way to keep it secure is to use an HSM for signing your data , in this case you can extend the JWT generator to sign the data through a crypto dll inside the HSM , this insures that the private key is never exposed outside the HSM
Whereas on the other hand if I generated my own tokens myself, and
stored a look-up table of 'one-way-hashed user id' => 'token',
Any one can generate your non-keyed hash. Secure hashes involved a private key which becomes a digital signature. Now we've come full circle, because that's exactly what a JWT token is.
Alternatively, you store them in a datastore, but now you must query this on every round trip. Most ticket(cookie)/token authentication systems use public key verification, which verifies the validity of the ticket/token without a database roundtrip.
If you store them in a datastore, now you must track expiration in the datastore as well. Tickets/tokens can have an expiration built into them. The nice thing about tickets/tokens is the client holds them. You can expire a session more quickly than the authentication. I.e. often you get a ticket that may allow you to be logged in for 2 hours, but the web server can expire your session in 10 minutes to reduce memory usage. When you access the web server in 15 minutes, it will see your ticket/token and see that it is still valid, and create a new session. This means at any point in time the server is tracking far fewer idle users.
JWT issuers are great for distributed systems, where authentication is shared. Rather than reimplement the authentication in every system, exposing multiple systems to the private key, as well as potential bugs in the authentication, we centralize it to one system. We can also leverage third party integrators that generate JWTs. All we need to do is get their public key for verifying the JWTs.
If someone breaks into your system and it is still secure, then you
made a secure system; nothing to worry about.
I have your list of nonces you were saving in your database now, and can login as anyone. I also likely have your connection strings, even if you're encrypting your application config, if I have root access then I can access the same key store that's used by the application to decrypt them. Now I get your username/passwords from your database and can login as anyone, regardless of what authentication scheme you use.
You'll be hard pressed to find a system that can still be secure after someone's gained root or physical access to the machine.
There's a small handful of systems that have purpose built hardware for storing keys and handle requests for encryption operations through an interface, thus ensuring the keys are protected at a hardware level and never accessed directly from software:
https://en.wikipedia.org/wiki/Hardware_security_module
I have done a lot of research and I can't work out if this is the best way to achieve what I need.
I have a generic web app and I want to create a generic mobile app to go with it. In order for users to save data/access user specific data/etc they have to log in and the login has to be authenticated over my web app's REST api.
So the api has a private and a public key for the mobile app. The public key tells me where the request is coming from (the mobile app) and the private key is used as a "salt" to hash the query string which can then be rehashed on the web server when the request comes in and compared for validity.
To log in the user enters their username and password which is then sent as query string vars as per the method above. The query is checked for validity at the other end and the username+password pair is checked against the database. If the login is correct a random "auth token" is generated for that user and the public key and sent back to the mobile app for storage locally on the device.
When the next request comes in from the mobile app one of the query string variables is the "auth token" from earlier which is checked for validity (with the app's public key) against the "auth tokens" table in the database. If it is valid then do the request.
My question here is, have I got this right? Is this the best way to achieve what I need? The last step seems really insecure as both the public key and the auth token will be visible if the request is intercepted. Obviously the request will be checked against the hash of the query string and the private key at the other end and this will make sure the request isn't coming from anywhere malicious.
Are there any other steps, or things I've missed which would be useful? For instance I was reading that there should also be a timestamp variable which should be checked against a 5/10min time frame in the request. Any timestamps older than 5/10 mins and the request should be rejected. Is this important?
Thank you.
What you are describing is basically a homebrew version of 2-legged OAuth. There are many implementations out there that you can basically use. Whenever it comes to security related stuff, I go by: If others have already done it, don't reinvent the wheel. OAuath is used by many big sites out there (Twitter, Facebook, GitHub, Google, ...) and they have done a lot of research that went into the OAuth standards. So I'd suggest to use those.
If you are concerned that messages you send may be intercepted, you should use HTTPS... Which is a good idea in general, if you are passing around username and password combinations over the wire.
I need to write a code to check the validity of the digital certificate present in an etoken.
I am not familiar with etokens. Can anyone please answer my following questions,
How to access the digital certificate content from etoken?
Can we access the private key stored in etoken?
When we plug the etoken to an computer then does it copy the digital certificate on the computer or not? If yes then where does it copy it?
I need to write C++ program for the same. Can we use Cryptographic API's (like CrypImportKey() CryptExportKey() ) provided by Microsoft for the above requirement?
"etoken" was the name of one of first USB cryptotokens produced by Aladdin. What you are asking for is usually referred to as security token. This is a hardware device with it's own memory, in which certificates and private keys are stored.
Tokens need drivers to be installed in order to work properly. The driver set includes implementation of CSP (Cryptographic Service Provider) for CryptoAPI. CSP does the job of presenting certificates, stored in the token, to CryptoAPI. To answer your questions:
Via CryptoAPI or PKCS#11 interface (drivers for both are supplied by the vendor).
You can perform certain operations with the private key by calling the appropriate API. But the key itself is not extractable.
I can't say for sure but for me it looks like certificates are copied to in-memory certificate store for speed of operations.
In relation to your second question, I believe it is possible to access the private key on the security token. The security token had to be pre-programmed and loaded with a private key somehow. Also, the last time we renewed our certificate, we did it online, using the issuer's web interface which installed an ActiveX module that uploaded the new certificate to the device. I don't know if this procedure also uploaded a new key but possibly not, since I don't believe you need to change your private key to create a new public certificate for yourself (which needs to be signed by the issuer to be trusted I believe).
Sorry I might not make much sense as I am new to the whole idea of Public Key Infrastructure.
If someone else could validate/invalidate my claims, please share your knowledge.
EDIT: I found this hardware hack for Alladin devices: http://seclists.org/bugtraq/2000/May/48
Basically, it is possible to read the date on the eToken but it requires a direct hardware interface to the device's on-board memory.
I'm developing a small app that will help users easily get information from their isp provider, by scrapping their isp account page. For that to be possible I need their username and password store in my db. To keep their password safe I will use an openssl public key to encode it in my db and a private key to decode it before my scraper logs in to their account page.
I'm wondering where to put my private key so the passwords are safe even if someone take controller of my web server? Because It would be totally inappropriate to just leave the private key on the web server...
tks
If someone takes total control of your server and is interested in those passwords, he will succeed. Always take this into consideration and make plans on what to do in this case.
Now to make it as hard as possible and improbable to achieve this, I suggest to store the key (or better, the passwords) in some kind of memory table: like a Ramdisk, a script that will give out only one password per minute and delete itself if called more than that etc.
I don't see any positive effect of using public key encryption here, the key to decrypt must be stored on the server no matter what you use. You may look for Howtos that descripe the problem of https-certificates, they should be protected by passphrases and must be read on server start - the problem is related.
Probably a good solution would be to log into the server, store the passwordfile in a ramdisk and log out. Repeat on Server reboot, crash or password change.