Advisory - Understand your organization’s readiness for change; build a strategy to address current challenges, performance, and KPIs

Keyrus

keyrus

SINGAPORE, Singapore, March 27th, 2024/Chainwire/-- OPZ Token ($OPZ) is an all-in-one solution that combines a wallet on iOS & Android, decentralized exchange, advanced AI trading, and NFC technology. It provides 1,000,000,000 tokens for traders. Using ERC-20, this token employs powerful AI trading technology to handle users' trades. Traders buy and hold the tokens, and the AI system then takes over, trading continuously on 10,000+ cryptocurrencies, such as Bitcoin, Ethereum, and Binance Coin. OPZ-AI: AI Analysis OPZ Token uses blockchain technology and sophisticated technology to accelerate and secure transactions. The team believes in the idea of AI in cryptocurrency- AI can analyze data, forecast trends, and automatically decide whether to buy or sell cryptocurrency. It helps study market patterns, forecasts how prices may change, and even decides whether to buy or sell coins without human assistance. Artificial Intelligence (AI) Combining AI and blockchain technology in cryptocurrencies builds a powerful team. Blockchain guarantees security and openness, and AI helps consumers make informed decisions about trading cryptocurrencies. Together, blockchain and AI improve the effectiveness and potential profitability of cryptocurrency trading. OPZ-AI revolutionizes cryptocurrency analysis by providing comprehensive, real-time insights and trend analyses for over 10,000 coins. Participating in the is simple, with prices starting at $0.028, and the launch price set at $0.1. OPZ Token Presale OPZ Wallet The OPZ Wallet addresses the growing demand for user-friendly and secure self-custodial solutions in the cryptocurrency space. Leveraging the innovative KeyFusion protocol, a form of Multi-Party Computation (MPC) technology, OPZ Wallet combines advanced security measures with intelligent, AI-driven insights to offer a superior self-custody experience. OPZ-DEX: Revolutionizing Bitcoin DeFi OPZ-DEX is a groundbreaking platform that leverages the robustness of Bitcoin's Layer 2 for decentralized trading. It features the Chronicle Matching Engine for high-performance, low-latency trading and employs Zero-Knowledge Rollups for enhanced transaction throughput and privacy. OPZ Token: Revolutionizing DeFi with Advanced AI Integration OPZ Token marks a significant advancement in cryptocurrency. It combines a wallet and exchange that is supercharged with advanced AI technology. OPZ is well-positioned to gain a significant share of the rapidly growing DeFi market. Moving forward, OPZ Token aims to push the boundaries of technological innovation while empowering investors and driving positive transformations. For more information, users can visit https://opz.com Users can join the OPZ Presale here. About OPZ OPZ's mission is to accelerate the transition to self-ownership of assets by bridging the gap between the cryptocurrency industry and the traditional financial world. Contact Louis Drummond info@opz.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here.

OPZ Launches AI-Powered Wallet On iOS/Android And Raises $200K+ Within Hours

A step-by-step guide for getting to https://localhost:3000 Here’s the scenario: You’re a developer, building a web application that will be deployed in production and served up with HTTPS. Meanwhile, as you work on your local machine, you’re testing at . It’s not that big of a deal, but you sure wish you could have . http://localhost:3000 https://localhost:3000 This article will walk you through how to set that up. Step-by-step, we’ll do the following: Create a certificate to make ourselves a Certificate Authority (CA) that can sign SSL certificates. Sign an SSL certificate for . localhost Start up a Node.js Express server that is served up using our SSL certificate. localhost Configure our browser (Chrome, Firefox) and our API client (Postman, Insomnia) to allow for certificates that are signed by ourselves as the Certificate Authority. Visit our local server endpoint with HTTPS, without any certificate security complaints from our browser or API client. Step 1: Generate a CA Certificate The Certificate Authority (CA) is the third-party who signs SSL certificates. They’re the trusted issuers of the Internet, trusted to do their due diligence that you are who you say you are — before they’ll issue you a certificate. Your operating system and your browser has a list of CA’s that they accept as authoritative. If you have a certificate signed by one of these CA’s, then your browser won’t complain. , no CA is going to issue you a certificate for . Why? Because you don’t own . Nobody does. So, the only way to get a CA to sign that certificate is to the CA that signs the certificate. Unfortunately localhost localhost be That’s our first step: generate a root CA certificate. ~$ mkdir cert
~$ cert
~/cert$ mkdir CA
~/cert$ CA ~/cert/CA$ openssl genrsa -out CA.key -des3 2048 ~/cert/CA$ openssl req -x509 -sha256 -new -nodes \
           -days 3650 -key CA.key -out CA.pem

~/cert/CA$ tree
.
├── CA.key
└── CA.pem cd cd # Generate a private key # Choose a simple passphrase for your key. Enter it, re-enter it. # Generate root CA certificate using that key (valid for 10 years) # Enter the passphrase that you chose for the key. # Choose defaults or enter certificate info as appropriate. Step 2: Generate Certificate, Signed By Our CA With CA key and certificate in hand, we can sign SSL certificates as that CA. We’ll need to generate a key and a certificate signing request. Create a new folder, and open a new file in that folder called : localhost.ext ~/cert$ mkdir localhost
~/cert$ localhost
~/cert/localhost$ touch localhost.ext cd This file will contain information that will be written into the signed SSL certificate. localhost.ext authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1 We’ll be creating a certificate that works for both and . You can add more domains (for example: ) or IP addresses (for example: ). If you do add more domain names, though, be sure to edit your file to have those domains point to your local machine ( ). localhost 127.0.0.1 DNS.2 = mysite.local IP.2 = 192.168.100.2 /etc/hosts 127.0.0.1 With our certificate settings in place, we generate a key, and then use the key to generate a certificate signing request (CSR): ~/cert/localhost$ openssl genrsa -out localhost.key -des3 2048 ~/cert/localhost$ openssl req -new -key localhost.key \
                  -out localhost.csr # Generate a private key # Choose a simple passphrase for your key. Enter it, re-enter it. # Generate certificate signing request using key. # Enter the passphrase that you chose for the key. # Choose defaults or enter information as appropriate. # Don't worry about entering anything for "challenge password" Now, with this certificate signing request, we “ask” the CA to sign a certificate for us: ~/cert/localhost$ openssl x509 -req - localhost.csr \
                  -CA ../CA/CA.pem -CAkey ../CA/CA.key \
                  -CAcreateserial -days 3650 -sha256 \
                  -extfile localhost.ext -out localhost.crt # Use the passphrase that you chose for the CA KEY in Step 1. in This command takes in the certificate signing request ( ), the CA certificate and key ( and ), and your certificate extensions file ( ). With those inputs, it generates your certificate file, which is good for 10 years. localhost.csr CA.pem CA.key localhost.ext localhost.crt You get a warning message that says . It’s nothing to worry about. Your certificate will still have been generated. (To get rid of that warning in the future, you can reference .) might unable to write 'random state' this post Our server will need the certificate file, but it will also need the key. We need to decrypt and store that file too: localhost.crt decrypted localhost.key ~/cert/localhost$ openssl rsa - localhost.key \
                  -out localhost.decrypted.key # Use the passphrase chosen for the localhost key, # which is NOT the same as the CA key. in Step 3: Create an Express Server with SSL Certificate Just to test that this works smoothly, we’re going to create a Node.js Express server that serves up “hello world” at . https://localhost:3000 Up in our folder, initialize a Node.js project, and add the and packages: cert express https ~/cert$ yarn init
...
~/cert$ yarn add express https
~/cert$ touch index.js # Accept all yarn defaults With all our pieces in place, this is what our file looks like: index.js fs = ( ) key = fs.readFileSync( ) cert = fs.readFileSync( ) express = ( ) app = express()

app.get( , (req, res, next) => {
  res.status( ).send( )
}) https = ( ) server = https.createServer({ key, cert }, app) port = server.listen(port, () => { .log( )
}) const require 'fs' const './localhost/localhost.decrypted.key' const './localhost/localhost.crt' const require 'express' const '/' 200 'Hello world!' const require 'https' const const 3000 console `Server is listening on https://localhost: ` ${port} Spin up the server: ~/cert$ node index.js
Server is listening on https://localhost:3000 Step 4: Test in Browser and API Client Now that we’re serving up our endpoint with SSL, let’s see what happens in our browser. We’ll use Chrome: Close, but not quite. We’re serving up our endpoint with SSL, and we can even inspect the signed certificate that’s attached. The problem is that Google Chrome that signed this certificate. And rightly so — why should Chrome (and the rest of the world) trust as a CA? does not trust the CA us We’ll deal with this. But first, let’s show what happens in Firefox: And, in Postman: And Insomnia: Everybody complains. But, that’s to be expected. Let’s fix this. Step 5: Import CA Certificate to Browsers In each browser, we need to import our CA certificate to add ourselves as a trusted CA. A quick note on security: You don’t want to go and thoughtlessly add to your list of Certificate Authorities. There are certainly malicious users out there trying to pose as a CA so that they can get you to accept some website (with a certificate signed by that malicious CA) as authentic. For the purposes of this exercise, since we are adding our own CA certificate as a trusted CA, this is a safe operation. In Chrome, open the “Manage Certificates” settings under “Security.” That can be found at . Under “Authorities,” click on the “Import” button: chrome://settings/certificates Choose your file for importing. Click on the box that says “Trust this certificate for identifying websites.” Click on “OK.” ~/cert/CA/CA.pem Now, with our CA trusted, let’s use Chrome to visit our endpoint again: Excellent! In Firefox, it’s a similar process. Open preferences, and navigate to “View Certificates.” From there, go to “Authorities” and click on “Import.” Again, choose the file for importing, checking “Trust this CA to identify websites.” Click on “OK.” CA.pem Now, we test in Firefox: Our browsers are all set up! They trust our CA, and they trust our certificate. Step 6: Configure and Test API Clients In API clients like Postman and Insomnia, the process is similar. However, you could also just , which gets you of the way there. Let’s look at our API clients one at a time. disable certificate validation most Getting mostly there, then all the way there, with Postman In Postman, open up settings and turn “SSL certificate verification” to “OFF.” When we re-send our request in Postman, it looks like this: We’re able to get a , which is pretty good. But we do have that red security warning because we turned off SSL certificate verification. The warning looks like this: 200 OK If we want to get to green, then we can add our CA to Postman, much like we do in our browsers. In Postman settings again, navigate to “Certificates” and then turn “CA Certificates” to “ON.” Select your file as the PEM file. all the way CA.pem Lastly, go back to “General” settings and turn “SSL certificate verification” back to “ON.” We run our request again, and this time we have a secure : 200 OK Insomnia Insomnia also has the option to turn off certificate verification. In “Preferences”, navigate down the general preferences to find and “Validate certificates.” uncheck When we re-run the request in Insomnia, here’s how it looks: It works! At the time of this writing, Insomnia’s desktop client for Ubuntu doesn’t yet have the ability to import your own trusted CA certificates. They’re for Ubuntu/Mac, and they’re too. working on it making progress for Windows Conclusion So, are probably kind of developer. You know, the kind that just to have served up with SSL. Even though you know that the CA, and you signed this SSL certificate , and tweaked your browser and API client settings to accept the certificate. But still, it just warms your heart to see a green lock in your address bar rather than a red warning. you that has localhost you’re yourself you If that’s you, consider yourself equipped. Photo credit (top): by on Rob King Unsplash Photo credit (bottom): Photo by on Clint Patterson Unsplash

How to Get SSL/HTTPS for Localhost

In this article I would like to show you how you could use the @ decorator, from the , in your application (both node and web) in one of the most elegant and simple ways. memoizeAsync utils-decorators library Let’s say we have the following class: SettingsProviderClient {
  getSettings(context): <SettingsDto> {
    ...
  }
} export class Promise As you can see, the getSettings is returning a Promise of SeettingsDto. Now let’s say that we would like to have some caching which will check if a call was made in the last 10 minutes to getSettings with the same context then it would be pulled from the cache and won’t be resolved again. First step, install the utils-decorators library: npm install --save utils-decorators r Second step, apply the @ memoizeAsync decorato : { memoizeAsync } ; SettingsProviderClient { ( * * ) getSettings(context): <SettingsDto> {
    ...
  }
} import from 'utils-decorators' export class @memoizeAsync 1000 60 10 // 10 minutes in ms Promise That’s all! Now you have a 10 minutes cache. Wait! there are more options In the next few paragraphs we will discuss the API and it’s more advanced configurations. @ memoizeAsync By default the decorator will put as the key of a cache entry the string which is generated by running JSON.stringify on the provided arguments to the decorated method. If you would like to change this behaviour then you will need to provide your own key resolver: Custom key resolving: ({
  keyResolver: context.id.toString(),
  expirationTimeMs: * * })
getSettings(context): <SettingsDto> {
  ...
} @memoizeAsync ( ) => context 1000 60 10 Promise The cache attribute is expecting to receive an object that implements the Cache interface ( ): which the JavaScriptMap object implements by default Cache<D> { : ; : D | ; : ;
    has: ;
} interface set ( ) => key: , value: D string void get ( ) => key: string null delete ( ) => key: string void ( ) => key: string boolean In many cases you have more than one instance of your application running, in this cases you might want to have a distributed cache which all the instances of the application can share. To achieve this you need to provide your custom cache which should implement the AsynCache interface Distributed cache: AsyncCache<D> { : < >; : <D> | < >; : < >;
    has: < >;
} interface set ( ) => key: , value: D string Promise void get ( ) => key: string Promise Promise null delete ( ) => key: string Promise void ( ) => key: string Promise boolean The AsyncCache interface resembles the Cache interface but notice that every operation is async (returning a Promise). For example, let’s say that we are using Redis (you can see a full implementation in this ) as our distributed cache: gist ({
  keyResolver: context.id.toString(),
  expirationTimeMs: * * ,
  cache: redisCache
})
getSettings(context): <SettingsDto> {
  ...
} @memoizeAsync ( ) => context 1000 60 10 Promise You probably noticed that both the local and the async caches are provided via the same cache attribute, so if we would like to use different caches for different environments we could achieve this with a simple condition check: Different cache types for different environments ({
  keyResolver: context.id.toString(),
  expirationTimeMs: * * ,
  cache: isProd() ? redisCache : Map()
})
getSettings(context): <SettingsDto> {
  ...
} @memoizeAsync ( ) => context 1000 60 10 new Promise Summery Almost every production app has a cache, and dealing with a cache might be painful and inconvenient. IMO, by using a decorator this ordeal becomes much more pleasant, elegant and clear. Previously published on Medium

How To Setup Caching in Nodejs

The Basics is a ey anagement ervice that let you create Cryptographic keys that you can use to encrypt and decrypt data and also other keys. You can read more about it . AWS KMS K M S here Important points about Keys Please note that the customer master keys(CMK) generated can only be used to encrypt small amount of data like passwords, RSA key. You can use AWS KMS CMKs to generate, encrypt, and decrypt data keys. However, AWS KMS does not store, manage, or track your data keys, or perform cryptographic operations with data keys. You must use and manage data keys outside of AWS KMS. KMS API uses AWS KMS CMK in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. To encrypt application data, use the server-side encryption features of an AWS service, or a client-side encryption library, such as the AWS Encryption SDK or the Amazon S3 encryption client. Scenario We want to create signup and login forms for a website. Passwords should be encrypted and stored in DynamoDB database. What do we need? KMS key to encrypt and decrypt data DynamoDB table to store password. Lambda functions & APIs to process Login and Sign up forms. Sign up/ Login forms in HTML. Lets Implement it as Serverless Application Model (SAM)! Lets first create the Key that we will use to encrypt and decrypt password. KmsKey: Type: AWS::KMS::Key Properties: Description: CMK for encrypting and decrypting KeyPolicy: Version: '2012-10-17' Id: key-default-1 Statement: - Sid: Enable IAM User Permissions Effect: Allow Principal: AWS: !Sub arn:aws:iam::${AWS::AccountId}:root Action: kms:* Resource: '*' - Sid: Allow administration of the key Effect: Allow Principal: AWS: !Sub arn:aws:iam::${AWS::AccountId}:user/${KeyAdmin} Action: - kms: Create* - kms: Describe* - kms: Enable* - kms: List* - kms: Put* - kms: Update* - kms: Revoke* - kms: Disable* - kms: Get* - kms: Delete* - kms: ScheduleKeyDeletion - kms: CancelKeyDeletion Resource: '*' - Sid: Allow use of the key Effect: Allow Principal: AWS: !Sub arn:aws:iam::${AWS::AccountId}:user/${KeyUser} Action: - kms: DescribeKey - kms: Encrypt - kms: Decrypt - kms: ReEncrypt* - kms: GenerateDataKey - kms: GenerateDataKeyWithoutPlaintext Resource: '*' The important thing in above snippet is the . KMS requires a Key Administrator and Key User. As a best practice your Key Administrator and Key User should be 2 separate user in your Organisation. We are allowing all permissions to the root users. KeyPolicy So if your key Administrator leaves the organisation, the root user will be able to delete this key. As you can see can manage the key but not use it and can only use the key. and are parameters in the SAM template. KeyAdmin KeyUser ${KeyAdmin} ${KeyUser} You would be asked to provide values for these parameters during SAM Deploy. Parameters: KeyAdmin: Type: String KeyUser: Type: String Next, we will create DynamoDB table. The partition key will be user id. This is enough. You can additional attributes as required. myDynamoDBTable: Type: AWS::DynamoDB::Table Properties: BillingMode: PAY_PER_REQUEST AttributeDefinitions: - AttributeName: "userid" AttributeType: "S" KeySchema: - AttributeName: "userid" KeyType: "HASH" Now, lets create the API and Lambda handler that will process the Signup and Login requests. ApiGatewaySignupApi: Type: AWS::Serverless::Api Properties: StageName: Prod Auth: UsagePlan: CreateUsagePlan: PER_API Description: Usage plan for this API Quota: Limit: 500 Period: MONTH Throttle: BurstLimit: 100 RateLimit: 50 SignupFunction: Type: AWS::Serverless::Function Properties: Environment: Variables: userTable: !Ref myDynamoDBTable keyid: !Ref KmsKey CodeUri: Lambda/ Handler: signup.lambda_handler Runtime: python3.8 Policies: - DynamoDBCrudPolicy: TableName: !Ref myDynamoDBTable - KMSEncryptPolicy: KeyId: !Ref KmsKey - KMSDecryptPolicy: KeyId: !Ref KmsKey Events: getCounter: Type: Api Properties: Path: /signup Method: POST RestApiId: !Ref ApiGatewaySignupApi ApiGatewayLoginApi: Type: AWS::Serverless::Api Properties: StageName: Prod Auth: UsagePlan: CreateUsagePlan: PER_API Description: Usage plan for this API Quota: Limit: 500 Period: MONTH Throttle: BurstLimit: 100 RateLimit: 50 LoginFunction: Type: AWS::Serverless::Function Properties: Environment: Variables: userTable: !Ref myDynamoDBTable keyid: !Ref KmsKey CodeUri: Lambda/ Handler: login.lambda_handler Runtime: python3.8 Policies: - DynamoDBCrudPolicy: TableName: !Ref myDynamoDBTable - KMSEncryptPolicy: KeyId: !Ref KmsKey - KMSDecryptPolicy: KeyId: !Ref KmsKey Events: getCounter: Type: Api Properties: Path: /login Method: POST RestApiId: !Ref ApiGatewayLoginApi Here, we are creating 2 Lambda handlers, one that handles signup and other handles the login. We are limiting the usage of API under property. This is to prevent abuse of our API. We are setting two environment variables, one for database table name and another for KMS key name. Auth We are not hard-coding the table/key names instead we let cloud formation to name it and we set it as environment variables with auto generated values. This will prevent name conflicts of resources and you can run multiple versions of your whole cloud environment. Then we set policy that allow Lambda to access DynamoDB and the key.  You can find 'out of box' SAM policy templates . here With , we create the API Gateway resources. Events The final part of SAM template is Output section. Outputs: ApiGatewaySignupApi: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${ApiGatewaySignupApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/signup/" SignupFunction: Description: "Sign Up Lambda Function ARN" Value: !GetAtt SignupFunction.Arn ApiGatewayLoginApi: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${ApiGatewayLoginApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/login/" LoginFunction: Description: "Login Lambda Function ARN" Value: !GetAtt LoginFunction.Arn We output 2 important URLs in above section, and ,  We use these URLsin the frontend HTML form's attribute. See below: ApiGatewayLoginApi ApiGatewaySignupApi action Sign Up Username: Password: < > html < > head </ > head < > body < > h1 </ > h1 < = = = > form action "https://51v5ifsje1.execute-api.us-east-2.amazonaws.com/Prod/signup/" enctype "application/x-www-form-urlencoded" method "POST" < > label </ > label < = = = > input type "text" name "uname" id "uname" </ > input < > br < > br < > label </ > label < = = = > input type "password" name "password" id "password" </ > input < > br < > br < = > input type "submit" </ > input </ > form </ > body </ > html Login username: password: < > html < > head </ > head < > body < > h1 </ > h1 < = = = > form action "https://4ezqeugqlf.execute-api.us-east-2.amazonaws.com/Prod/login/" enctype "application/x-www-form-urlencoded" method "POST" < > label </ > label < = = = > input type "text" name "uname" id "uname" </ > input < > br < > br < > label </ > label < = = = > input type "password" name "password" id "password" </ > input < > br < > br < = > input type "submit" </ > submit </ > form </ > body </ > html In HTML, we are using encoding type as "enctype="application/x-www-form-urlencoded". With this type of encoding, the form data is sent in below format. username=doryfish&password=nemo The last piece in the puzzle is the Lambda handlers. Lets check it out. Python uses to access AWS. Boto3 json urllib.parse parse_qs urllib.parse boto3 logging os base64

log = logging.getLogger()
log.setLevel(logging.INFO) log.info(event)
    log.info(event.get( ))
    qs = parse_qs(event.get( ))
    log.info(qs)
    uname = qs.get( )[ ] 
    pwd = qs.get( )[ ]
 
    dynamodb = boto3.resource( )
    table = dynamodb.Table(os.environ[ ])

    log.info( +os.environ[ ])
    key = os.environ[ ]
    client = boto3.client( ) response = client.encrypt(
    Plaintext=pwd,
    KeyId=key
    )
    log.info(response[ ])
    b64_pass = str(base64.b64encode(response[ ]), )
    log.info(b64_pass)
   
    response = table.update_item(
        Key={ : uname
        },
        AttributeUpdates={ : { : b64_pass,
            }
            }
        )
    data = {}
    data[ ] = json_data = json.dumps(data) { : , : json_data
    } import from import import import import import import : def lambda_handler (event, context) "body" "body" "uname" 0 "password" 0 'dynamodb' 'userTable' 'key id:' 'keyid' 'keyid' 'kms' #Encrypt password 'CiphertextBlob' 'CiphertextBlob' 'utf-8' 'userid' 'password' 'Value' 'status' 'Signup Success' return 'statusCode' 200 'body' The first two statements are logging statements, this is useful in debugging and the log statements will be logged in CloudWatch logs. The module is used to read the form data from object. parse_qs event Data are returned as a dictionary. The dictionary keys are the unique query variable names and the values are lists of values for each name. Hence, in next 2 statements, we get the first value for each of type - uname and password. We retrieve the DynamoDB table using the table name from environment variable - .  Environment variables in Lambda can be accessed using . userTable os.environ['key'] Now we got the username and password.  Its time to encrypt the password and store it in DB. Password to encrypt is passed to attribute of the encrypt request and key id is retrieved from environment variable. Plaintext is the encrypted binary value in the response object. For example: CiphertextBlob '\x01\x02\x02\x00x\x9dN"\xa4\xf9\xfe\xb4\xc7&\x01\xdc\xb6J\xdf\xf1\xdc\xf2;)|7\x1b\'{8\xe6(\x80Q\xe5\x11\x8c\x010w"-\x11w\x10b\x9d\xd0w\xa7+\xd1\xa5\xc5\x00\x00\x00e0c\x06\t*\x86H\x86\xf7\r\x01\x07\x06\xa0V0T\x02\x01\x000O\x06\t*\x86H\x86\xf7\r\x01\x07\x010\x1e\x06\t`\x86H\x01e\x03\x04\x01.0\x11\x04\x0ca\xb4\xaa\x00\x10\xc0\xd1\xa6r\x07\xce\xc7\x02\x01\x10\x80"@\nL\xde<\x03s\xc6\xe0g\x80\xd4\x87\x8e\x1e\t\xa2\xac\x10\xfek\xb6\x1d\xf3\x87\x910\xabf\xd1d}x\xdb' Now we convert this binary value to ASCII text using str(base64.b64encode(response[ ]), ) 'CiphertextBlob' 'utf-8' and the end result we store it in database. AQICAHidTiKk+f xyYB LZK /Hc jspfDcbJ s iiAUeURjAEwdyItEXcQYp Qd cr aXFAAAAZTBjBgkqhki w BBwagVjBUAgEAME GCSqGSIb DQEHATAeBglghkgBZQMEAS wEQQMYbSqABDA aZyB HAgEQgCJACkzePA JoqwQ/mu HfOHkTCrZtFkfXjb 60 3 3 8 3 45 3 6 0 G9 0 8 3 4 0 87 NzxuBngNSHjh4 2 In Login Lambda handler, username and password is retrieved from the request like we did in Sign Up. json urllib.parse parse_qs urllib.parse boto3 secrets logging os base64

log = logging.getLogger()
log.setLevel(logging.INFO) log.info(event.get( ))
    qs = parse_qs(event.get( ))
  
    uname = qs.get( )[ ] 
    pwd = qs.get( )[ ]
    
    dynamodb = boto3.resource( )

    table = dynamodb.Table(os.environ[ ])
    response = table.get_item(Key={ : uname})
    json_str =  json.dumps( response[ ]) resp_dict = json.loads(json_str)
    dbpass = resp_dict.get( ) log.info( +os.environ[ ])
    key = os.environ[ ]
    client = boto3.client( )
   
    response = client.decrypt(
    CiphertextBlob=(base64.b64decode(dbpass)),
    KeyId=key
    )
    log.info( )
    decryptedPass = response[ ].decode( )
    
    response = {} decryptedPass == pwd : 
      response[ ] = { : , : json.dumps(response) 
      } :
     response[ ] = { : , : json.dumps(response) 
      } import from import import import import import import import : def lambda_handler (event, context) "body" "body" "uname" 0 "password" 0 'dynamodb' 'userTable' 'userid' 'Item' #using json.loads will turn your data into a python dictionary "password" #Decrypt password 'key id:' 'keyid' 'keyid' 'kms' "Decrypted value" 'Plaintext' 'UTF-8' if 'status' 'Login Success' return 'statusCode' 200 'body' else 'status' 'Login Failed' return 'statusCode' 200 'body' In decrypt request, the encrypted password string from database is converted into binary using and passed to the attribute. Decrypted password is returned as bytes in attribute of response. base64.b64decode(dbpass) CiphertextBlob Plaintext The password is encoded in UTF-8 to get the final decrypted password. The decrypted password is then compared with the password from the request and if it matches, response is sent back. 'Login Success' Phew! Finally, we are done coding.. Lets test it out. Lets do SAM build and Deploy. Stack creation complete! Testing Note that we are not deploying HTML forms as static site on S3 but we will locally open the forms in browser and hit the APIs. Add username/password, hit submit. Sign Up is Successful! Item in database. Password is encrypted Now, Login using the same username and password Login Success! Source Code: https://github.com/rajanpanchal/aws-kms-signup-login In next post, we will extend this example to use AWS STS! Previously published at https://rajanpanchal.net/aws-kms-solution/

How To Unite AWS KMS with Serverless Application Model (SAM)

An audit trail is a record of all changes made to a data model. A model is any entity that can be stored in a database, such as a user or a product. An audit entry typically contains information about the type of change (creation, update, or deletion), made the change, and the change was made. Audit trails are often used in large applications where there is need to track changes to one or more models over time. who when In this tutorial, we’ll set up an audit trail dashboard accessible to admins for a simple stock application. Our dashboard will update in realtime, allowing us to see updates as they happen. Here’s a preview of our app in action: Prerequisites PHP 7.1.3 or higher Composer A Pusher account. Create one . here Setup We’ll start out with a small stock management application I built. You can clone the project from GitHub by running: git clone https://github.com/shalvah/stockt.git You can also download the source directly from this link. Then into the project folder and install dependencies: cd composer install Next, copy the to a new file called . Run the following command to generate an application encryption key: .env.example .env php artisan key:generate Lastly, create a file called in the directory and run the following command to set up and populate the database: database.sqlite database php artisan migrate --seed Creating the audit dashboard We’ll use the package to handle auditing. Let’s install the package: laravel-auditing composer require owen-it/laravel-auditing Next, we’ll publish the database migrations for the audit tables and run them: php artisan auditing:installphp artisan migrate We’re going to be auditing changes to products. Let’s configure our product model so the auditing package can track it. In your model ( ): Product app/Models/Product.php the trait use OwenIt\Auditing\Auditable the interface: implement OwenIt\Auditing\Contracts\Auditable <?php namespace App\\Models;  
  
use Illuminate\\Database\\Eloquent\\Model;  
use OwenIt\\Auditing\\Contracts\\Auditable;  
  
class Product extends Model implements Auditable  
{  
  use \\OwenIt\\Auditing\\Auditable;  
  
  // ...  
} Now, whenever a change is made to a product, the details of the change will be recorded in the table. audits We need to make a small change to our auditing configuration so the model can properly map to our model. This will enable us to write code like to retrieve the name of the user who made the change. In the file , replace the value of in the array with the class name of our User model ( ) Audit User $audit→user→name config/audit.php model user App\Models\User::class 'user' => ['primary_key' => 'id','foreign_key' => 'user_id', // replace the line below  
  'model'       => App\\User::class,  
      
  // with this  
  'model'       => App\\Models\\User::class,  
\], Now, on to the audits dashboard. First, we’ll create a middleware that allows only admin users to view the page. Create a file called .php in with the following content: AllowOnlyAdmin app/Http/Middleware <?php namespace App\\Http\\Middleware;  
  
use Closure;  
use Illuminate\\Support\\Facades\\Auth;  
  
class AllowOnlyAdmin  
{  
    public function handle($request, Closure $next)  
    {  
        if (Auth::user()->is\_admin) {  
            return $next($request);  
        }  
          
        abort(403);  
    }  
} Next, add the route for the audits at the end of your : routes/web.php Route::get('audits', 'AuditController@index')->middleware('auth', \App\Http\Middleware\AllowOnlyAdmin::class); Let’s create the controller. We’ll generate the file .php by running: app/Http/Controllers/AuditController php artisan make:controller AuditController Create an method within the class with the following content: index AuditController public function index(){$audits = \OwenIt\Auditing\Models\Audit::with('user')->orderBy('created_at', 'desc')->get();return view('audits', ['audits' => $audits]);} Let’s build the view for our audits. Create the file with the following content: resources/views/audits.blade.php ('layouts.app') @extends [@section](http://twitter.com/section "Twitter profile for @section")('content')  
  <div class="container">  
    <table class="table" >  
      <thead class="thead-dark">  
        <tr>  
          <th scope="col">Model</th>  
          <th scope="col">Action</th>  
          <th scope="col">User</th>  
          <th scope="col">Time</th>  
          <th scope="col">Old Values</th>  
          <th scope="col">New Values</th>  
        </tr>  
      </thead>  
      <tbody id="audits">  
        [@foreach](http://twitter.com/foreach "Twitter profile for @foreach")($audits as $audit)  
          <tr>  
            <td>{{ $audit->auditable\_type }} (id: {{ $audit->auditable\_id }})</td>  
            <td>{{ $audit->event }}</td>  
            <td>{{ $audit->user->name }}</td>  
            <td>{{ $audit->created\_at }}</td>  
            <td>  
              <table class="table">  
                [@foreach](http://twitter.com/foreach "Twitter profile for @foreach")($audit->old\_values as $attribute => $value)  
                  <tr>  
                    <td><b>{{ $attribute }}</b></td>  
                    <td>{{ $value }}</td>  
                  </tr>  
                [@endforeach](http://twitter.com/endforeach "Twitter profile for @endforeach")  
              </table>  
            </td>  
            <td>  
              <table class="table">  
                [@foreach](http://twitter.com/foreach "Twitter profile for @foreach")($audit->new\_values as $attribute => $value)  
                  <tr>  
                    <td><b>{{ $attribute }}</b></td>  
                    <td>{{ $value }}</td>  
                  </tr>  
                [@endforeach](http://twitter.com/endforeach "Twitter profile for @endforeach")  
              </table>  
            </td>  
          </tr>  
        [@endforeach](http://twitter.com/endforeach "Twitter profile for @endforeach")  
      </tbody>  
    </table>  
  
  </div>  
[@endsection](http://twitter.com/endsection "Twitter profile for @endsection") You can start your app by running: php artisan serve Then visit your app on . The app comes with two default users: an admin user (Administrator, ), and a regular user (John Doe, ). (Both passwords: ) Sign in to your app as John Doe and as Administrator and make changes to some of the products displayed on the homepage. Then visit as Administrator to see the list of all changes made by all users. http://localhost:8000 stockt admin@stockt.test john@stockt.test secret http://localhost:8000/audits Displaying new audits in realtime Now we’ve got our audit dashboard working, but we need to reload the page whenever we wish to see any new changes. This is where our realtime functionality, powered by Pusher, comes in. Let’s implement it. First, we’ll set up Pusher on the backend. Install the Pusher Laravel package: composer require pusher/pusher-http-laravel php artisan vendor:publish --provider="Pusher\Laravel\PusherServiceProvider" Edit your so it looks like this: config/pusher.php 'connections' => ['main' => ['auth_key' => env('PUSHER_APP_KEY'),'secret' => env('PUSHER_APP_SECRET'),'app_id' => env('PUSHER_APP_ID'),'options' => ['cluster' => env('PUSHER_APP_CLUSTER'),],'host' => null,'port' => null,'timeout' => null,],], Sign in to and create a new app. Copy your app credentials from the section and add them to your file: your Pusher dashboard App Keys .env PUSHER_APP_ID=your-app-idPUSHER_APP_KEY=your-app-keyPUSHER_APP_SECRET=your-app-secretPUSHER_APP_CLUSTER=your-app-cluster Note: Laravel sometimes caches old configuration, so for the project to see your new configuration values, you might need to run the command _php artisan config:clear_ The package fires an event called whenever a new audit is created. We’ll listen for this event and trigger a event on Pusher. Our frontend will listen for this event and add the new audit item to the table. laravel-auditing Audited new-audit Create the event listener, with the following content: app/Listeners/AuditedListener.php <?php namespace App\\Listeners;  
  
use OwenIt\\Auditing\\Events\\Audited;  
use Pusher\\Laravel\\Facades\\Pusher;  
  
class AuditedListener  
{  
  public function handle(Audited $event)  
  {  
    $audit = $event->audit->toArray();  
    $audit\['user\_name'\] = $event->audit->user->name;  
    Pusher::trigger('audits', 'new-audit', \['audit' => $audit\]);  
  }  
} Next, we’ll register the event listener in the : app/Providers/EventServiceProvider.php class EventServiceProvider extends ServiceProvider{protected $listen = [\OwenIt\Auditing\Events\Audited::class => [\App\Listeners\AuditedListener::class]]; // ...  
} Here’s the code we’ll use to handle the event. We pull in the library, subscribe to the channel and bind to the event. When an event comes in, we build up a new row and insert it at the top of the table. Add the code to the end of your : pusher-js audits new-audit resources/views/audits.blade.php <script src=" "></script><script>var socket = new Pusher("your-app-key", {cluster: 'your-app-cluster',});socket.subscribe('audits').bind('new-audit', function (data) {var audit = data.audit;var $modelCell = $('<td>').text(audit.auditable_type + '(id: ' + audit.auditable_id + ')');var $eventCell = $('<td>').text(audit.event);var $userCell = $('<td>').text(audit.user_name);var $timeCell = $('<td>').text(audit.created_at); https://js.pusher.com/4.2/pusher.min.js function createSubTable(values) {  
            var $table = $('<table>').addClass('table');  
              for (attribute in values) {  
                $table.append(  
                  $('<tr>').append(  
                    $('<td>').text(attribute),  
                    $('<td>').text(values\[attribute\])  
                  )  
                );  
              }  
              return $table;  
          }  
  
          var $oldValuesTable = createSubTable(audit.old\_values)  
          var $newValuesTable = createSubTable(audit.new\_values)  
  
          var $oldValuesCell = $('<td>').append($oldValuesTable);  
          var $newValuesCell = $('<td>').append($newValuesTable);  
  
          $newRow = $('<tr>').append(  
            $modelCell,  
            $eventCell,  
            $userCell,  
            $timeCell,  
            $oldValuesCell,  
            $newValuesCell  
          );  
          $('#audits').prepend($newRow);  
      });  
</script> Replace and with your Pusher app key and cluster, and we’re done! your-app-key your-app-cluster Let’s test the app. Start your app as described earlier. Sign in as John Doe in one browser and Administrator in another so you can maintain concurrent sessions. Try making changes to some products as John Doe while viewing the dashboard as Administrator. The changes should show up on the dashboard in realtime. Conclusion In this article, we’ve added an audit dashboard to an existing application. We’ve gone ahead to add realtime functionality by displaying audits on the dashboard as they happen. Thanks to Laravel and Pusher, we were able to achieve these with minimal stress. You can check out the source code of the completed application on . GitHub Originally published on Pusher’s blog .

How to add a realtime audit trail to your Laravel project

Hacking Android phone. How deep the rabbit hole goes.

Setting the Stage Late 2013 and early 2014 proved to be a watershed with regards to public understanding of digital privacy and security. We learned a lot about what intelligence organizations, both U.S. and foreign, had been doing in terms of surveillance both domestically and internationally. I’d hypothesize that many — ?most? — Information Security professionals assumed the level of intelligence collection capabilities that the Snowden leaks proved…but no-one had ever confirmed it. Obviously, no-one SHOULD have confirmed anything, but… that’s what happened. Due to at Target, Home Depot, Dairy Queen, Albertsons, UPS, JP Morgan Chase, Staples and KMart, the security of our commerce and communications systems was repeatedly called into question. The fact that service providers were into our lives and turning us into commodities became common knowledge. These revelations about government and corporate access to our personal data and communications brought Internet privacy and security to the forefront of our collective consciousness. Topics that had previously been the domain of old UNIX greybeards and IT nerds became hot topics for the nightly news and congressional hearings. breaches snooping With these events as a backdrop, the company that I work for, , announced it was looking for a new technology to incubate and launch. I spent a considerable amount of time building systems for the government in the areas of attribution management and online anonymity. My experience working in and for the government drove me to the conclusion that Internet privacy presents three fundamental problems: Kyrus Tech are . In this model, users exchange privacy and security for free and convenient access. Ubiquitous free Internet and services becoming the norm The organizations best positioned to enact proper privacy controls are the ones with the least incentive to do so. When businesses are expected to provide their services for free, they . find other ways to make money In our current “always on” and “always connected” world, and perimeters are largely a thing of the past. everyone is a traveler In other words, I saw a set of problems or harms that would never be solved by those who solve them. To do so would undermine their real goal: making money at the expense of our privacy. I decided to do something about it and Kyrus backed my idea. Our goal: Create a scalable cloud platform to provide privacy, security, and anonymity — accessible to all Internet users. Strong security, delivered simply. should How does IDVector help resolve these issues? addresses critical data protection and privacy concerns by providing a simple, scalable solution to encrypt your data in transit and provide diversified Internet access paths to ensure privacy, security, and anonymity when required. IDVector To do this, we’ve devised several core technologies which fall into two basic categories: Client Devices and/or Software Ephemeral, on-demand, cloud-based network redirection and egress nodes There are currently : the IDVector Pro USB client and the IDVector Mobile client for iOS. The Pro client is a small form factor USB powered device that has at its core an Atmel System on Chip and WiFi chipset. It is runs a custom Linux implementation and uses both proprietary (patent pending) client software and commodity Open Source VPN software. A hardware device allows us to solve some problems that software solutions simply cannot do alone. two clients First and most simply, we provide an additional layer of security — good old defense-in-depth. By using an offboard WiFi device, we move the external facing surface area off of a user’s laptop hardware and software. In other words, we keep your laptop’s hardware and Operating System isolated from unknown and possibly insecure WiFi while still allowing you to access the Internet via these free connections. Second, we introduce some new concepts and features. We created a pre-negotiation or captive portal protection proxy which ensures that you can’t be attacked while your computer is negotiating your connection. This functionality was inspired by a series of attacks against business travelers, nicknamed “ ”. In these attacks, the captive portal systems at hotels were compromised and malware was installed that would based on their personal details. This malware presented itself while users were negotiating the hotel captive portal (entering their room number, last name, etc). Most importantly, the malware was presented to the travelers as a legitimate software update with a valid ( ) cryptographic signature, and so the target systems downloaded and installed it as if it were a valid update. Our captive portal protection proxy technology prevents binary code from reaching the client computer by stopping it at the IDVector Pro client layer. We also allow users to automatically and randomly change the WiFi MAC address of their IDVector Pro client. This helps to prevent “free WiFi” providers from profiling users or targeting them based on a previously collected MAC address. Darkhotel target specific travelers though weak Finally, IDVector clients allow the user to choose to access the Internet via an IDVector Shared Path or a custom Private Path. Shared paths are inexpensive and available to all IDVector users. Shared paths have a limited lifespan and are automatically created and destroyed periodically using new server instances, new cryptographic keys and new IP addresses. IDVector Private Paths are completely private — they are hosted on dedicated cloud servers that are created and destroyed at the click of a button. With both Shared and Private Paths you choose where in the world you want to appear on the Internet. The cryptographic material that secures the Pro client’s connection to both types of paths is never used for more than one connection and is generated on the IDVector Pro client. The IDVector servers never possess the client’s cryptographic keys. literally On the mobile side, we provide an iOS app that does many of the same things as the Pro client, from within the Apple iOS platform. Because Apple and iOS are somewhat restrictive, there are some limitations. For example, we can’t implement the captive portal protection proxy because Apple has its own iOS device captive portal negotiation mechanism. Much of the rest of the IDVector technology passes straight through to the iOS client. You can use Shared Paths or Private Paths and all of your data goes through the secure and private VPN technology exiting the path wherever you want it to, world wide. Our IDVector Mobile client for Android should be available early in the 4th quarter of 2016. In the Cloud we use a variety of providers to achieve global coverage. We leverage Apache LibCloud to control our cloud instances. LibCloud allows us to quickly and easily add more providers as demand increases for particular regions. Our Cloud infrastructure is incredibly scalable; we’re excited to test how far it can grow. As noted above, because cryptographic material for Pro Client VPN connections is generated on the client device, we (as the service provider) snoop on the traffic of our customers. All VPN paths use IKEv2 with Perfect Forward Secrecy as a default. We designed the system from the start to take ourselves out of the loop. CANNOT All of your important data should already be encrypted between your web browser and the server, but with IDVector neither we nor the big data collection platforms can tell who you are, where your data originated, and in many cases, where it is eventually ending up. Even if you use a corporate or personal VPN to encrypt traffic from your system to your remote work environment and/or the Internet, your system is still directly connected to insecure WiFi and is therefore vulnerable to local attacks as well as data collection schemes that can see the source and destination of your encrypted data streams. IDVector blocks those attacks and masks the endpoint of all of your network traffic. There is a that shows (at a high level) how it all works. diagram on our web page Because we truly think that privacy, security, and anonymity are important, we allow users to pay for IDVector service through anonymous mechanisms. To that end, we have selected Stripe as our payment processing partner in part because they accept BitCoin. If you aren’t interested in the cryptocurrency space, the best “old fashioned” anonymous payment mechanism is prepaid cards — which Stripe also supports. So, who needs IDVector? We think everyone needs IDVector — we’re all travelers in a perimeter-free world. As a starting point, we’re focusing on 5 core groups: Corporate Executives — people targeted both because of their access to information and their likelihood to conduct business in a variety of insecure places. Information Security Professionals — Incident Responders, Forensic Analysts, Reverse Engineers, and others who conduct open source intelligence collection and don’t want corporate or private IP addresses in server logs. Lawyers, Medical Organizations, Media and Content Creators — people who are responsible for protecting other people’s privacy, anonymity, rights, content and intellectual property. Journalists — all of them. Whether they are investigative journalists working with sensitive sources or are themselves operating out of denied territory under restrictive regimes. Journalists can protect themselves and their sources with IDVector. Government travelers -Department of Defense, Department of State, or any federal employee who may find themselves abroad but without a secure way to communicate with their headquarters. Our long term road-map includes an Enterprise offering as well as exploring incorporation of IDVector technology into small office and home office (SoHo) routers. We believe geographically dispersed teams should be able to create dynamic secure and private shared work spaces. We believe every individual ought to be able to surf from their home without fear of their service provider snooping into their traffic. Enterprise and SoHo versions of IDVector technology will enable these scenarios.

Stories, News & Mentions about KEYRUS

Keyrus’s Stories on HackerNoon