Felhasználó reg átadás

Geva képe

Át kellene adnom a honlapon regisztrált felhasználó email címét és password-jét - WCF REST felé, app-k használatához.
A megadott JSON formátumba a user által megadott password titkosítatlan szövegét kérik, az összekészített motyó egyedi kulccsal és password-l kerül titkosításra, majd Base64 és URLEncode.
- a password hash https://api.drupal.org/api/drupal/includes!password.inc/function/user_ha... szerint,
kérdésem:
hogyan lehet a jelszót regisztrációnál megcsípni mielőtt titkosításra kerülne, egyáltalán lehet-e?

Vissza lehet-e kódolni a már elérhető hash-elt jelszót? ...rules-ben, views-ban, eddig csak nemleges válaszokat találtam,

Mi erre a megoldás? ...először dolgozom web service-l,
köszönök előre is minden segítséget.
Geva

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
aboros képe

Vissza lehet-e kódolni a már elérhető hash-elt jelszót?

nem. ez pedig by design, így biztonságos.

a jelszót talán el tudod csípni a regisztrációs űrlap (vagy user edit) esetében úgy, hogy egy form_alterral saját függvényt fűzöl a submit lánchoz és elkapod a jelszót még a hashelés előtt. kérdés, hogy ez mennyire etikus, főleg mennyire biztonságos, hogy plain text letárolod a jelszót. (pláne, hogy plain text egy webservicenek elküldöd...) másik jó kérdés, hogy erre miért van szükség?

1
0

-
clear: both;

nevergone képe

Egyetértek aborossal, a jelszó nem állítható vissza a tárolt értékből, ez a hash lényege. A jelszavat én is a belépési formon keresztül kapnám el, a Joomla modul kódjából tudsz lesni:
http://cgit.drupalcode.org/joomla/tree/joomla.module?h=7.x-2.x&id=6631a0...

A jelszó plaintext utaztatása nem feltétlen rizikós, ha maga az átviteli csatorna kódolt, pl. SSL, HTTPS.
Viszont kódolatlan jelszavat ne tárolj el sehol és ne küldj kódolatlan csatornán (pl. email, HTTP), mert ez hatalmas biztonsági kockázatot jelent!

0
0
Geva képe

köszönöm a megerősítést és a tippet

0
0
Geva képe

köszönöm a nem megerősítését,
amiért erre szükség van: a felhasználók a honlapon regisztrálnak és applikációkat tudnak elérni vele,
etikusság: nem tárolom le a passwordot sehol, továbbítani is titkosítva, amint azt írtam is, JSON formában összeállítva a csomagot, majd azt titkosítva jelszó + salt

0
0
aboros képe

nem kell neked kézzel összecsomagolni az ilyesmit. például: https://www.drupal.org/project/rest_auth
(bár nem értem pontosan, de arra is van kész megoldás, hogy appból lépsz be drupalba meg arra is hogy drupalla lépsz be másik szervizbe)

0
0

-
clear: both;

Geva képe

ez a pontos felállás(a drupal oldal az enyém, a többi kész tény :-) a tervezésnél nem kérdeztek meg), mind a honlap mind pedig az applikáció a crm-el áll kapcsolatban, a drupal és az app között közvetlen kommunikáció nincs.
A felhasználó regisztrál a honlapon és az applikáción jut a szolgáltatásokhoz, böngészhet a crm-ben tárolt adatok között, a honlapon megadott email és password segítségével. Az applikáció egy dot netes, windows-s app

- a drupal a crm-től kapja a híreket, az esetleges hír törlést is - feeds importáló figyeli a könyvtárat és veszi cron futásnál ha valami érkezett, ez már Ok

- a drupal a regisztrációs adatokat egy windows-s web service-t meghívva tudja átadni, REST típusó ws, azaz egy útvonal meghívásával. Az url-ben küldött információ JSON formátumú, megadott oszlályokkal, amelyet titkosítani kellene PCLCrypto alapján - megadott kulcsszóval és salt-al, utána Base64 + UrlEncode átalakításokkal. Ezt az információt a web service egy methodusa veszi és ad rá választ. A választ természetesen dekódolni kell a honlapon.

Erre nem találtam meg a megfelelő modulok láncolatát(services + services_views-al ugyan elkészül a küldendő, de ott is kézzel kellene elkészíteni a titkosítást), így nem is vagyok a feladattal kész - csak teljesen :-) - egyre inkább megoldhatatlannak tűnik a PCLCrypto!

...szerinted? ...már semmiben sem vagyok biztos :-(
üdv Éva

0
0