Software Architecture Fundamentals - Episode 11 - Securing data at rest and in transition

Are you a software developer who wants to understand better software architectures? In this stream, we discuss all the needed software architecture basics you need to know.

Don't forget to follow me on Twitter @laurspilca or LinkedIn for more posts and discussions.

[Boria]

Very interesting and important information described in simple words. Laurentiu thanks for your effort.

[unam]

Thank you for the excellent series and commitment to make us understand the concepts .

I understand that a sender having the public key encrypts the data, sends it and the receiver decrypts it with the private key. If so, isn't the sender (having the public key) be also allowed to sign the data and the receiver (with the private key) verifies if the signature is intact ? why is it happening the other way around ? Do you also have a scenario to explain this .

[tenchopapazov]

Hi Laur, your content rocks! I have a question in terms of the asymmetric keys. If you have an authorization server for example that accepts user credentials and like you said the app should not rely solely on the https. Is it good practice to save public and private keys in a vault and then when the login or register form is loaded to provide that public key in the front-end in order to encrypt randomly generated symmetric key that encrypts the user data(symmetric key is included as it's better for larger data encryption) and by sending the encrypted user data and encrypted symmetric key to the server in the request body the auth server should be the only one to see the typed user sensitive data as an envelope? I hope I explained my idea behind that security concern :)

[TrueJohnCa]

These lessons are great, thank you so much. I have a question about the example of the downloaded file verification at the end of the video. Both the file and the hash string are served by the same site (xampp in this case) that is also shown as secure by the browser (with the little padlock icon). So how is the hash string more trustable than the file? I mean, couldn't the man in the middle replace both the file and the hash string that I will use to verify it?