There are 2 nfs shares on our linux redhat servers to host the live and landing data. There is keytab refreshed ( ticket produced) every 30 minutes , apparently it give system account an access to those 2 shared drives. If key tab ticket is not valid then i guess we would get key is expired error on browsing those 2 nfs locations.
This is what documented as a part of handover from other team. I don't have test env and I got to replace the keytab from rc4 to aes but my problem is that I don't know how keytab is associated with those 2 locations? . It seems it encrypts the locations and allow the access to them with keytab only.
Do I need to change any conf file to replace keytab from rc4 to aes. Kerb cong has already got entry to allow new encryption types aes128.
Unix , nfs storage and ad teams are not giving me answer and i am new to all of this. I have read online that there is sssd.conf file that could be used in conjunction with kerb conf . Can you give me direction from your experience
I'm going to store root and intermediate certificates (from different CA) into some KVStore.
The problem: I have a leaf certificate (only) that I want to validate based on certificates from my store. The leaf certificate has Authority Key Identifier == Subject Key Identifier of a parent that already must be present in the KVStore.
Question: What should I use as a Key in KVStore?
1.Subject Key Identifier:certificate or it can be the same within single CA or different CAs. what about renewal or keys rotation?
2.Subject Key Identifier + Subject DN: certificate - not sure that there is a difference with first.
3.Subject Key Identifier: list[certificate]
4.Serial Number + Issuer is unique but leaf certificate doesn't contain this date about parent.
The Subject Key Identifier is a hash value over the certified public key. Thus, depending on the CA's key rotation policy this may or may not change during certificate renewal. It is therefore not guaranteed that the mapping SKI:certificate is unique.
A combined index as in option 2 does not change that.
Option 4 should be ruled out since the child certificate does not know the issuer and serial number of its parent.
Option 3 may be a valid solution in most cases, however, the Authority Key Identifier extension is not mandatory for X.509 certificates. So you may have to deal with leaf certificates without the AKI extension.
This typically leads to option 5: Subject DN: list[certificate]. Preferably with a sorted list that has the most likely CA certificate on top.
However, if your application only deals with leaf certificates with an AKI extension and all CA certificates require a key rotation during renewal option 1 may be a tick more performant. In that case I'd also keep an entry Subject DN: list[Subject Key Identifier].
I've two Face API endpoints. One in US West and another in Central India. The one in US West works fine but the Central India endpoint is throwing 401 error.
{"error":{"code":"Unspecified","message":"Access denied due to invalid subscription key. Make sure you are subscribed to an API you are trying to call and provide the right key."}}
I've verified all the endpoint, keys, location etc as mentioned in the blog (https://blogs.msdn.microsoft.com/kwill/2017/05/17/http-401-access-denied-when-calling-azure-cognitive-services-apis/)
Is there anything else I can try?
This is crazy! I deleted the resource and created it again and it started working. The only change I made was chose a new resource group instead of selecting an existing one. Gosh!
The Skyscanner API gives different results than Skyscanner website.
For the flight from any airport in Warsaw to any airport in Wrocław, if I use the API the cheapest option is 303.99 zł.
This flight is operated by LOT (LO). Other available flights are operated either by LOT (LO) or by Lufthansa (LH).
On the other hand, if I make the same query using Skyscanner website, the cheapest flight costs 42 zł and is operated by Ryanair (FR).
link: https://www.skyscanner.net/transport/flights/wars/wro/161111/161112/airfares-from-warsaw-to-wroclaw-in-november-2016.html?adults=1&children=0&adultsv2=1&childrenv2=&infants=0&cabinclass=economy&rtn=1&preferdirects=false&outboundaltsenabled=false&inboundaltsenabled=false&ref=home#results
However, if I uncheck Ryanair at the left hand side panel, I receive very similar results to those from the API.
Link: https://www.skyscanner.net/transport/flights/wars/wro/161111/161112/airfares-from-warsaw-to-wroclaw-in-november-2016.html?adults=1&children=0&adultsv2=1&childrenv2=&infants=0&cabinclass=economy&rtn=1&preferdirects=false&outboundaltsenabled=false&inboundaltsenabled=false&ref=home#results
What is more, if I enter the API test as an unlogged user, I can again retrieve the Ryanair flight. The test is available at: http://business.skyscanner.net/portal/en-GB/Documentation/FlightsLivePricingQuickStart
Images:
Can you reproduce this behavior? Is there something I am doing wrong about the API? How can I retrieve Ryanair’s prices programmatically?
I don't think you're doing anything wrong, I've the same problem. In fact, I've taken the example apiKey from the test site and copied it to my code (for testing), and it shows Ryanair flights. But not with my apiKey. It appears that they are deliberately excluding Ryanair from the regular api results. I've contacted Skyscanner for Business support weeks ago, and haven't received a reply.
EDIT
I'm still hoping for some advice on this, i tried to clarify my intentions...
When i came upon device pairing in my mobile communication framework i studied a lot of papers on this topic and and also got some input from previous questions here. But, i didn't find a ready to implement protocol solution - so i invented a derivate and as i'm no crypto geek i'm not sure about the security caveats of the final solution:
The main questions are
Is SHA256 sufficient as a commit function?
Is the addition of the shared secret as an authentication info in the commit string safe?
What is the overall security of the 1024 bit group DH
I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible?
What may be the most promising attack (besides ripping the device out off my numb, cold hands)
This is the algorithm sketch
For first time pairing, a solution proposed in "Key agreement in peer-to-peer wireless networks" (DH-SC) is implemented. I based it on a commitment derived from:
A fix "UUID" for the communicating entity/role (128 bit, sent at protocol start, before commitment)
The public DH key (192 bit private key, based on the 1024 bit Oakley group)
A 24 bit random challenge
Commit is computed using SHA256
c = sha256( UUID || DH pub || Chall)
Both parties exchange this commitment, open and transfer the plain content of the above values.
Alice Bob
ca = commit()
-------^ ca
cb = commit()
cb ^-----------
open
---^ DH pub a, chall a
open
DH pub b, chall b ^---
The 24 bit random is displayed to the user for manual authentication
DH session key (128 bytes, see above) is computed
When the user opts for persistent pairing, the session key is stored with the remote UUID as a shared secret
Next time devices connect, commit is computed by additionally hashing the previous DH session key before the random challenge. For sure it is not transfered when opening.
c = sha256( UUID || DH pub || DH sess || Chall)
Now the user is not bothered authenticating when the local party can derive the same commitment using his own, stored previous DH session key. After succesful connection the new DH session key becomes the new shared secret.
As this does not exactly fit the protocols i found so far (and as such their security proofs), i'd be very interested to get an opinion from some more crypto enabled guys here. BTW. i did read about the "EKE" protocol, but i'm not sure what the extra security level is.
"Is SHA256 sufficient as a commit function?"
The use of SHA256 should be just fine. The only issue I have heard of is that it has a hash extension vulnerability. If you produce multiple hashes using the same data don't simply concat more data to the end of the data you already hashed. In your post have have the two hashes "sha256( UUID || DH pub || Chall)" and "sha256( UUID || DH pub || DH sess || Chall)". If that second one was "sha256( UUID || DH pub || Chall || DH sess)" then there would be a relation between the hash values if UUID, DH pub, and Chall were all the same values as before. You should either take care to avoid the hash extension issue or include a salt value into the data to be hashed, either by communicating the salt across the link or having differing vales for each code path.
On a side note: is it really necessary to transmit a Chall when you already have a previous session key saved and don't need to ask the user to manually confirm the challenge code?
"Is the addition of the shared secret as an authentication info in the commit string safe?"
I'm guessing you mean to ask "Is it safe to include secret information in a hash that is to be made public?" If the secret is something that is really hard to guess and would take a really long time to perform a bruteforce attack against, then yes it is safe. If the secret is something easy to guess or has only a few possible values, then no, it's not safe unless you, at the same time, include some hard to guess secret to force a potential eavesdropper to have to guess all such secrets simultaneously. For a large, effectively random number like a DH shared secret then it should be just fine.
"What is the overall security of the 1024 bit group DH"
I'm not sure if DH group 1024 is what you want to use. A key exchange that is considered to be close to being as effective as the SHA256 hash algorithm you're using would be 521 bit ECDH. The cryptographic strength of ECDH is considered to be 1/2, so if you want 256 bit security, you want 521 bit ECDH. Unfortunately, I'm not certain about the security of the many individual 521 bit ECDH groups that have been published.
"I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible?"
There is more than one way perform a MITM attack. Eve will use every resource at her disposal to perform her attacks and if you are not careful she will exploit something you didn't think of. This is why peer review is necessary in cryptography.
Simply, if you make your own cryptographic solution, then it's weak.
for the little story, the VISA guys have to start again 4 times before it's became strong enough.
I'm not a security expert, but it was what my crypto teacher told us everytime.
I've come up with this possible attack, based on my understanding of the protocol, inspired by Lowe's Attack to Needham-Shroeder Public Key Protocol:
Alice wants to reconnect. Calculates its committment ca and sends to Bob. The message is captured by Mallory.
Mallory answers. She does not know the shared secret, so she invents one. Calculates cb and sends to Alice.
At this step, Alice cannot verify the shared secret yet. So she sends DHpubA and ChallA.
Mallory ignores the messages from Alice and disappears.
Now Mallory has a valid DHpubA, ChallA and the corresponding (valid) ca.
Mallory sends ca to Bob.
Bob answers with cb.
Mallory sends a valid set of DhpubA, ChallA
Bob sends his DhpubB and ChallB
Since Bob can validate Mallory's messages, she is authenticated as Alice. Obviously Mallory does not know DHprivA, se she cannot calculate the current session key, but nevertheless you have a security flaw since Bob thinks he's talking to Alice.
General advice: avoid implementing you own cryptographic solution and don't trust security reviews from anyone else than an established security firm.
If you feel that your security requirements are not satisfied by standard mainstream crypto, try stating your requirements and asking whether is there a security procotol that matches them.
That sounds OK. Not sure what you meant by "fix[ed] UUID"?
Could a rogue app access the UUID and session keys: are they stored system-wide or in a service? There is some text in the SDK that suggests that any keystore always waits for user confirmation before returning a key.