Wachtwoorden opslaan

[josvane]

Voor mijn bedrijf is het de bedoeling dat wij een klantenportaal gaan (laten) bouwen. We willen met dit portaal processen gaan automatiseren, waardoor ik enerzijds minder handelingen heb om een klant operationeel werkend te krijgen op ons telefonieplatform maar anderzijds dat klanten inzicht krijgen in hun verbruik, facturen en instellingen.

Er zullen een aantal stappen handmatig blijven maar grof wil ik naar deze stappen toe.

1. - Klant besteld op onze website een telefonieoplossing, deze gegevens worden opgeslagen in de database.
2. - De klant krijgt een login en daarmee toegang tot het portaal en krijgt een overzicht van zijn systeem.
3. - De configuratie wordt gemaakt en opgeslagen.
4. - De instelling worden gepusht naar ons telefonie platform.

Omdat wij als bedrijf onze security erg serieus nemen moeten we dus goed nadenken over de beveiligingrisico's die er zijn.
Een login om op het klantenportaal te komen is geen probleem, hier zijn voldoende methodes voor om dit te realiseren.
Om configuratiewijzigingen te pushen naar toestellen is het nodig om het wachtwoord van het betreffende toestel beschikbaar te hebben.

Hier zit dan voor nu ook een risico, hoe ga ik deze wachtwoorden opslaan. Ik kan zelf twee methodes bedenken.

1. Wachtwoorden hashen middels een salt. De salt moet dan ingegeven worden op het moment dat er wijzigingen gedaan worden in de instellingen. Dit is echter in mindere maten gebruiksvriendelijk en in basis het idee van Keepass.
2. Werken met een front en back-end systeem. De front-end db heeft alle instellingen, de backend haalt eens in de zoveel tijd deze instellingen naar zich toe. Doordat de backend-end alleen data naar zich toe haalt hoeft hier geen publiek internet op uitgezonderd 3306 naar het IP van de front-end en kan hij in die DB het wachtwoord er bij halen. Deze backend hangt kan via de VPN communiceren naar het platform en de settings pushen.

Concreet is mijn vraag dus hoe jullie dit zouden aanpakken?

Ik open dit topic omdat ik (nogmaals) beveiliging serieus neem en mij daar ook verantwoordelijk voor voel. Ik wil op deze manier een uitgangspunt (PvE) creëren richting het bedrijf/persoon die dit moet bouwen.

Ik had deze vraag ook geplaatst op mijn blog, maar kreeg toch het advies hem hier te plaatsen. Als hij in het verkeerde topic staat, sorry hé.

[Nvidiot]

De salt kan prima in de database staan, naast de hash van het wachtwoord. De salt is bedacht om ervoor te zorgen dat je niet een password hash kunt opzoeken in een vooraf gemaakte database (rainbow tables), en is dus geen user-input. Verder zou ik voor de hash functie dit gebruiken: Wikipedia: PBKDF2.

[Zoijar]

Ik snap je situatie nog niet helemaal. Je moet dus feitelijk instellingen uit een database naar een telefoon pushen, en daarvoor heb je het wachtwoord van de telefoon nodig? Dan kan je helemaal niks hashen, want je hebt de feitelijke wachtwoorden nodig. Encrypted column in een database met telefoon/wachtwoord paren, en een sync process dat wijzigingen uit je settings haalt en naar de desbetreffende telefoon pusht. Sync en wachtwoord database inderdaad op een niet toegangkelijke machine. De crypt op je column is niet echt security tegen mensen die toegang tot die machine hebben, daar kan je niet 100% tegen beveiligen, meer tegen de casual observers van je database. Beetje als de "sterretjes" in windows

[josvane]

@Zoijar. Om mijn verhaal te verduidelijken, Mijn portal/database gaat niet direct naar het toestel pushen. Ik moet deze informatie pushen naar de VoiP-server (externe partij). Om mijzelf te authenticeren moet ik het wachtwoord mee sturen van het betreffende device. Het voipplatform handelt zelf de communicatie af met het toestel, waarbij deze ook de firmware e.d. regelt.

Jammer genoeg heeft het voip platform (broadsoft) geen api, maar alleen een XML interface.

[Kalentum]

Misschien is dit wat?

Het password van de gebruiker in jullie systeem sla je gehashed op en is dus niet bekend bij jullie
Het password van de externe voip-server sla je encrypted op met als key het password van de gebruiker van jullie systeem, dus het plain text password

Als de database wordt gestolen, zijn alle passwords veilig:
- De voip-passwords zijn alleen terug te halen met de key van de gebruiker
- De encryptiekey van het voip-password is zijn front-endpassword, dat jullie niet in plain text in de database hebben staan

Bij inloggen op jullie portal geeft de gebruiker een wachtwoord in, dat dan gebruikt wordt om de voip-passwords te decrypten. Deze moet je dan wel ergens gedurende de inlogsessie van de gebruiker bewaren op de server, bv in een browsersessie. Maar ja je hebt uiteindelijk toch op een gegeven moment het echte wachtwoord nodig om in te loggen op die voip-server.

[ Voor 3% gewijzigd door Kalentum op 28-09-2014 11:42 ]

[josvane]

@rutgerw, het portaal gaat wel op HTTPS draaien, maar dit het wachtwoord plain text opslaan is volgens ten alle tijden een no go.

[Kalentum]

Ik zeg nergens dat je het wachtwoord plain text moet opslaan. Ik bedoelde dat je het plain text wachtwoord dat de gebruiker van jullie portal gebruikt als key wordt ingezet. Jullie weten dat wachtwoord niet en slaan het ook niet plain text op.

Wat je opslaat is dit:
- Hashed wachtwoord van de gebruiker. Dit wachtwoord is niet terug te leiden naar plain text
- Encrypted wachtwoord voor het voip-systeem. Je gebruikt het plain text wachtwoord van de gebruiker (die je krijgt als de gebruiker inlogt maar dus niet opslaat) om de wachtwoorden van de voip-servers te decrypten.

Je zult toch ergens een encrypted wachtwoord een keer moeten decrypten, anders kun je nooit met de juiste credentials inloggen op die voip-service

[DJMaze]

Werk met een private en public key.
Op de public server het toestel wachtwoord encrypten met de public key,
Op de private server het toestel wachtwoord decrypten met de private key.

Gebruiker wachtwoord kan gewoon met BCrypt

[ Voor 11% gewijzigd door DJMaze op 01-10-2014 12:38 ]