Alternative for Gravatar which supports SHA256 - gravatar

In our c# application we are not using MD5 as it is not secure, we are using SHA256. but when we use SHA256 we are not getting any images from gravatar. My questions are
will gravatar support SHA 256?
what is the alternative to gravatar that supports SHA256, We don't want to install or include any libraries as gravatar requires just the URL to get he image.

As MSalters already mentioned, I don't think it really matters in this use case. You're not doing anything cryptographic, so I don't think there are any issues with MD5 in this scenario. However, if you do specifically want an alternative that supports SHA-256 hashes of emails to get user avatars (though definitely not as popular as gravatar), there's Libravatar. Libravatar's API documentation does state that it supports SHA-256 for retrieving avatars.

Related

Cloudflare worker generate smime signature

Generating smime (CMS) signature with node-forge working good on Cloudflare Worker Editor, but When I deploy the code, I'm getting CPU Timeout (Error 1102).
So, I assume, when I call signature.sign({ detached: true });, it just taking time to generate signature.
I'm using Business: 50ms.
So,
Is it possible to increase node-forge process by setting any properties?
Is there any other alternative other then node-forge which I can use (expecting some example, I studies pkijs)
Looking for guide line.
Unfortunately, cryptographic algorithms implemented in pure JavaScript are likely to run very slowly and exceed the current CPU time limits imposed by Workers.
Instead, try using the WebCrypto API. Workers supports some of WebCrypto, and in particular it supports generating signatures in RSASSA-PKCS1-v1_5 format. Based on a quick Google search it looks like this may be what you need for S/MIME.
CloudFlare has added WebCrypto to the workers recently. You really dont want to use JS crypto, Forge is full of it, see Javascript Cryptography Considered Harmful for why.
If what you want is a pure crypto signature you don't even need PKIjs, just use it directly
If you really want S/MIME a look at PKIjs and use WebCrypto. the S/MIME examples.

Zapier Twilio credentials storage: how safe is that?

While creating a Twilio Zap (and others), we are required to provide the Account Sid and the Account Token for your existing Twilio account.
I suppose this is stored by Zapier somewhere (hopefully with reversible crypto), otherwise they cannot execute future requests. Does anybody know how safe is this? Have they published any information about how they protect this data?
EDIT
Well, nothing some googling couldn't help
https://zapier.com/help/data-privacy/
Yes, they encrypt the data with AES and store the keys separately. I guess there will always be the danger of data breaches, but that's the trade-off.
I just wonder why their own login credentials use SHA (with 1000 iterations), while I believe the most recommended would be bcrypt.
Zapier co-founder here, we've recently updated to use PBKDF2 with 10k iterations (the standard Django hashing scheme). We'll progressively update these from time to time as standards dictate.

Generate rsa keypair client-side on the browser

I'm not very expert in this kind of programming, and I know there is several similar questions, but anyone answered exactly that I need.
My team (and I) are developing a Public Key Infrastructure. We are stuck in the key generation (on client side), but we found so few documentation about it.
We know there are these options:
keygen tag --> generates a SPKAC request --> works in Mozilla to internal keystore, token and smartcard
crypto.generateCRMFRequest() --> generates a CRMF Request --> works in Mozilla to internal keystore, token and smartcard
CryptoAPI, CAPI, XEnroll CEnroll --> generates a CSR PKCS#10 (I think so) --> Works in Internet Explorer (we still haven't found code's examples)
Javascript or java Applet (yes I know, both are different) generates in all with sunpkcs11, bouncycastle or iaik API (can't reach any goal)
We found this options. but we don't know how to get the results, how to create to a CSR PKCS#10 request and how to handle it.
please, could you give me an advice about select the strategy, find how to implement and handle results, convert results and so? we are getting crazy!
Example: we know how to use the keygen tag, but we don't know how to set the key to only RSA 2048, and how to handle the SPKAC request to convert in a good CSR signed on SHA256
We tried to develop a Java Applet with iaik API, but the CSR generated had an error.
You are correct on all counts, as far as using browser tags to generate the keypair and/or certificate request. I recommend you take a look at the Odyssi CS project on Sourceforge. It's a very simple CA implementation written in Java/JSP. Take a look at the JSP files and you can see how the various options are being passed to the key generation tags.
Basically, you generate the keypair as part of a form submission. From there, they're available in the same way as any other request parameter. You'll need to know how to decode them on the backend. IE generates the request as a PKCS#10, which is nice since it's a well-documented standard. The SPKAC format isn't as widely used, but there are still good documentation and libraries available.
http://sourceforge.net/projects/odyssipki/
As Daniel pointed out, SPKAC is not broadly supported (even by CAs), it would be better if viable for your case to use PKCS10 in all browsers.
Here is an example doing that - https://github.com/PeculiarVentures/csrhelp

App Engine: what are best practices for transmitting a password and storing it securely in Google App Engine?

I'm wondering what is the state-of-the-art of transmitting passwords from a web form and storing them in the data store.
A lot of recent posts point to bcrypt, however, there are no pure Python implementations, which is a requirement for App Engine.
Any suggestions?
Best practice? Use the Users API with either Google Accounts or OpenID, so you're not storing or transmitting passwords in the first place.
If you must do it yourself, transmit the login data over SSL, and store the password hashed, salted, and strengthened, using a scheme such as PBKDF2.
You can use PyCrypto which has been ported to google-app-engine.
You should never store the actual passwords, of course. Storing a hash should be sufficient. When the user enters his password, you hash it again and compare it to the stored value.
You should of course only receive passwords over https, which is supported in google-app-engine (albeit only through you appspot domain)
BCrypt has been ported to Python some time ago. I've been using it gracefully since then.

How would you implement salted passwords in Tomcat 5.5

My web application is relying on container-managed security and I'm wondering if it's possible to use salted passwords at all. As far as I can tell it's easy enough to store digested passwords in a database by just configuring a JDBC or DataSource Realm, but there's no way to add a salt to those digest.
Any suggestions?
Edit: it seems I just need to think some more before asking questions ;-)
It's just a matter of choosing who's doing the digest calculation (client or server) and configure Tomcat accordingly.
If you're creating and storing the digests you can create and store the salts at the same time.
Your auth table would contain
....
pwdDigest varchar(64), -- or int256 if you have one
hashSalt int64,
....
Then depending on the auth protocol you're using you either send the hashSalt to the client when you get the username for client side encryption or use it to hash the password if you receive it in clear.
I'm not familiar with the database access technologies you're talking about, so I apologise if I've missed the point and oversimplified the answer.
Tomcat 5.5 and 6.0 don't support salted passwords in JDBCRealms and DataSourceRealms. It's a known bug, and the suggested patch seems to work fine, but it wasn't accepted yet.
If you don't want to apply the patch you can at least use it as an implementation example:
Bug 45871 - Support for salted and digested patches in DataSourceRealm
Passord-based encryption in JCE uses salt as per PKCS#5. See http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html#PBEEx for an example.

Resources